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Tnis  tnesls  presents  tne  specification,  design  anc 
implementation  of  a  prototype  microcomputer  system  for  tne 
target  information  section  of  tne  Marine  Corps  fire  support 
coordination  center.  Currently,  tne  tar»e  t  information 
section  uses  a  series  of  index  cards,  Handwritten  lists, 
acetate  covered  battle  maps  and  erease  pencils  to  perform 
tne  target  information  functions. 

Tne  taesis  examines  and  analyzes  taese  functions  in 
detail  and  proposes  a  solution  in  tne  form  of  a  system,  data 
Dase  and  interactive  user  design.  Tne  resultant 
Microcompute r  System  for  Tar?et  Information  (MISTI}  employs 
an  ALTOS  Z-?2  microcomputer ,  tne  'JCSD  Pascal  operating 
system,  a  user  friendly  interface  and  data  base  tecfcnoloey. 
It  is  proposed  as  an  interim  system  until  tne  ^arir.e 
Integrated  Fire  and  Air  Support  System  ( MI FAS S }  becomes 
operations  1 . 
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INTRODUCTION 


A.  THE  PROBLEM 

More  and  more  of  tne  applications  of  modern  amphibious 
warfare,  from  real-time  combat  systems  to  tne  data  oases 
tnat  control  tne  men,  materiel  and  resources  needed  to  wage 
war,  nave  turned  to  computerized  solutions.  Tne  products  of 
tne  technological  explosion  nave  enabled  tne  Navy-Marine 
Corps  amphiDious  team  to  do  more,  to  do  it  faster  and  to  do 
it  witn  a  degree  of  efficiency  and  accuracy  previously 
unobtainable . 

Tnis  evolution  of  modern  technology  nas  not  yet  reacned 
tne  Marine  Corps  tactical  command  posts  established  on  tne 
beachhead.  The  target  information  section  of  tne  landing 
force  fire  support  coordination  center  (FSCC)  plays  a 
signficant  role  in  tne  conduct  of  effective  coordination  of 
tactical  air,  artillery  ana  naval  gunfire  support  on  targets 
of  nigh  priority,  fet  the  target  information  officer  ar.d  nis 
staff  accomplish  their  important  taslc  by  tne  use  of  index 
card  files,  cross-reference  files,  hand  written  lists  of 
targets  and  colored  grease  pencils  on  acetate-covered 
tactical  maps.  This  metnod  is  time  consuming,  slow  in 
response  to  inquires  about  target  information,  tedious  and 
difficult  to  maintain  in  a  current  status  and  does  not 
provide  information  in  a  sufficiently  timely  and  accurate 


manner.  It  Is  40  year  oil  technology  In  the  age  of 
computers . 

Tne  requirement  to  automate  many  of  tne  functions  of  tne 
tactical  command  post  nas  been  identified  and  tne  command 
post  of  the  future  is  beine  planned  for  and  developed  now. 
Until  It  arrives,  there  is  a  need  to  provide  an  interim 
capability  to  the  landlntt  force.  An  automated  solution  to 
tne  target  Information  function  will  simplify  the  tasx  of 
tne  target  information  section  considerably,  will  provide 
rapid,  accurate  and  timely  target  information  to  tne  members 
of  the  FSCC,  and  can  be  made  operational  now,  five  full 
years  before  tne  planned  introduction  of  tne  computerized 
command  post. 

Tnis  tnesis  contends  tnat  tne  automation  of  tne  target 
Information  function  is  necessary  to  improve  tne  operational 
capability  of  tne  landing  force  FSCC  and  tnat  implementation 
of  a  suitable  and  effective  tareet  information  system  is 
possible.  Tnis  tnesis  will  prove  this  contention  by 
implementing  and  designing  a  wortcing  prototype  which  will 
increase  operational  effectiveness  immediately  as  well  as 
provide  a  testbed  and  learning  model  for  tne  future 
automated  command  post.  The  prototype  will  be  designed  to 
perform  all  tne  duties  and  functions  of  tne  target 
information  section  as  currently  stated  in  doctrinal 
publications.  The  interim  system  will  hopefully  contribute 
to  the  development  of  tne  future  system  and  identify  areas 
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of  concern  and  improvement  before  tne  future  Marine  Corps 
system  becomes  operational. 

B.  BACKGROUND 

An  important  aspect  of  ampnibious  fire  support 
coordination  (tne  planning  and  execution  of  tactical  air, 
artillery  and  naval  gunfire  support  so  tnat  targets  are 
adequately  covered  by  a  suitable  weapon  or  group  or  weapons) 
is  tne  function  of  target  information.  One  of  tne  major 
duties  of  tne  fire  support  coordinator,  tnat  member  of  tr.e 
landing  force  staff  responsible  for  coordination  of  fire 
support,  is  to  ensure  tnat  tne  fire  support  coordination 
center  receives  and  disseminates  available  target 
information  to  all  staff  sections  and  commands  requiring  tne 
information.  He  also  must  work  closely  witn  tne  target 
information  officer  and  tne  commander  and  nis  staff  in  tne 
selection  of  targets  and  assignment  of  classification  and 
attack  priorities. 

Target  Information  is  tne  direct  application  of  combat 
intelligence  to  fire  support  and  is  a  Key  to  tne  proper 
employment  of  supporting  arms  in  conjunction  witn  earn  of 
the  plans  of  the  ampnibious  operation.  Effective  fire 
support  coordination  and  the  planning  of  ampnibious 
operations  generate  a  continuing  requirement  for  target 
acquisition,  dissemination,  evaluation  and  recommendation 
for  attack. 
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To  accomplish  this  important  tasx,  tne  commander  of  tne 
amphibious  taste  force  assigns  a  target  intelligence  officer 
to  the  supporting  arms  coordination  center  (SACC).  This 
officer  operates  tne  target  information  center  (TIC)  and 
worrs  closely  with  tne  air  intelligence  officer,  tne  landing 
force  targeting  representatives  and  the  supporting  arms 
coordinator.  The  commander  of  the  landine  force  has  a  target 
information  officer  (TIO)  wno  operates  tne  target 
information  section  (TIS)  as  an  integral  part  of  tne  landing 
force  fire  support  coordination  center  and  a  target 
intelligence  officer  who  functions  in  the  landing  force 
intelligence  center. 

The  Navy  staff  uses  a  computerized  target  information 
system  wnicn  is  part  of  tne  snipooard  Amphibious  Support 
Information  System  (ASIS)  and  maintains  tne  list  of  targets 
as  part  of  a  data  base.  Target  information  operations  in  tne 
SACC  are  thus  computerized  and,  while  tne  ASIS  target  system 
is  not  tne  most  modern  of  data  case  systems,  it  is 
efficient,  effective  and  fast.  <fhen  tne  functional 
responsibility  for  maintaining  targets  is  passed  asnore  to 
the  landins  force  TIO,  the  computer  system  is  replaced  by  an 
index  card  filing  system,  wnicn,  wnlie  effective,  is  neither 
fast  nor  efficient  by  comparison.  Additionally,  the  index 
card  system  lends  itself  to  inaccuracies  and  omissions  in 
target  data,  particularly  when  the  information  must  be 
maintained  in  a  timely  manner.  The  tactical  requirement  for 
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accurate  and  timely  target  information  is  no  less  critical 
or  important  when  the  landing  force  Is  on  tee  beach,  yet  tne 


system  to  accomplish  tnis  taste  is  antiquated  and  cumbersome. 

The  staff  of  the  TIS  manually  transfers  the  target 
information  lata  contained  in  the  ASIS  data  base  to  5  cy  8 
inch  target  cards.  After  duplicating  the  entire  target  file, 
tne  TIS  must  construct  a  cross  reference  file  to  list  tne 
target  by  grid  location  and  a  cross-index  file  to  Keep  tracK 
of  certain  types  of  targets.  In  addition  to  tne  target 
cards,  the  TIS  also  mates  up  lists  of  particular  categories 
of  targets  which  may  be  of  interest  or  value  to  members  of 
the  FSCC. 

The  TIS  obtains  intelligence  information  from  landing 
force  and  supporting  arms  agencies,  converts  tnis  to  target 
information  and  enters  the  information  into  the  target  card 
files.  The  information  is  made  available  to  tne  supporting 
arms  representatives  in  the  FSCC  and,  based  on  the  TIO's 
recommendations,  a  decision  is  made  when  and  cow  to  attacK  a 
particular  target.  Results  of  attaexs  on  targets,  front  line 
reports  and  intelligence  information  are  used  to  refine  tne 
target  list  and  delete  or  deprioritize  those  targets  that 
present  a  diminished  tnreat  to  the  landing  force. 

Access  to  specific  information  from  the  target  list  (for 
example,  more  than  one  category  of  tne  cross-index  files) 
requires  physically  searching  tnrougn  each  list  and 
constructing  sub-lists  to  determine  tne  appropriate 
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timely  and 


Information.  Tne  constant  avaiiaoility  of 
accurate  target  information  is  reauired  for  tee  effective 
employment  of  supporting  arms  and  planning  of  fire  support. 
Tne  Tli  plays  a  itey  role  in  providing  tnis  information  and 
tne  constant  process  of  adding  to  tne  target  list,  selecting 
targets  for  attacx  and  deleting  targets  once  neutralized  is 
performed  by  tne  TIS  staff  using  tne  target  card  file. 

C.  INTEGRATED  FIRE  AND  AIR  SUPPORT  SISTE* 

One  of  tne  most  complex  ascents  of  modern  amphibious 
warfare  is  tne  control  and  coordination  of  supporting  arms 
particularly  in  tne  transition  of  responsl oility  from  tne 
Navy  in  ampnibious  snips  to  tne  Marine  Corps  combat  units 
asnore.  The  grease  pencils,  map  boards  and  field  radios  tnat 
nave  served  Marines  so  well  since  tne  days  of  Guadalcanal 
will,  in  tne  future,  be  eclipsed  by  tne  automated  system 
called  tne  Marine  Integrated  Fire  and  Air  Support  System 
(MIFASS). 

MIFASS  is  part  of  tne  Marine  Corps  integrated  command 
and  control  system  called  MTACCS  (Marine  Tactical  Command 
and  Control  Systems),  a  collection  of  eignt  major  systems 


wnicn  will  give 

the 

Marines 

a 

capability  of  exercising 

real-time 

command 

and 

control 

of 

combat  forces  in  tne 

pos  t-1980 

time 

frame . 

MIFASS 

is 

designed  to  perform  tne 

functions  of  tne  fire  support  coordination  center,  (FSCC^ 
tne  direct  air  support  center  (DASC)  and,  to  a  degree,  tne 


artillery  fire  direction  center  (FDC)  at  one  central 
location  called  tne  Fire  and  Air  Support  Center  (FASC1. 

It  is  a  distributed  processing  system  in  whi~h 
microcomputers  control  Interactive  display  devices,  manage 
data  bases,  perform  computational  tasics  and  drive  printers 
to  provide  card-copy  records  of  messages  ana  operator 
decisions.  It  is  currently  in  full  scale  engineering 
development  witn  an  initial  operational  capability  planned 
for  tne  1986-1987  time  frame.  MIFASS  addresses  tne 
requirement  for  target  information  by  providing  tne  TIO  witn 
a  digital  display  device  wnich  will  nave  botn  a  graphical 
representation  of  tne  target  on  a  battle  map  and  a  video 
screen  for  alphanumeric  display  of  target  information. 

D.  NATURE  OF  THE  PROBLEM 

An  automated  solution  to  tne  target  information  function 
will  not  be  realized  until  tne  introduction  of  tne  MIFASS 
computers  into  tne  Fleet  Marine  Forces.  Until  sucn  time  as 
the  system  is  delivered,  tne  target  information  function  of 
tne  FSCC  is  tied  to  tne  current  doctrine  and  tne  target  card 
filing  system. 

In  this  report,  an  interim  systems  solution  to  tne 
problem  of  automating  tne  target  information  function  of  tne 
FSCC  is  presented.  It  computerizes  those  basic  functions  of 
tne  TIS  in  a  simple,  Inexpensive  and  effective  manner.  It 
simplifies  tne  tasics  of  tne  TIS,  provides  a  mechanism  for 
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rapid  and  accurate  retrieval  of  target  information  ana  could 
improve  the  operational  capability  of  the  FSCC. 

S.  NATURE  OF  THE  SOLUTION 

Tne  amount  of  target  information  tnat  needs  to  be 
processed  is  sufficiently  small  tnat  a  microcomputer  is  tne 
most  suitable  piece  of  hardware  for  implementation.  The 
current  versions  of  microcomputers  are  very  versatile  witn 
efficient  operating  systems,  various  input/output  media 
including  video  terminals,  inexpensive  and  relatively 
portable  secondary  storage  media  (floppy  disKettes  and 
cassettes),  nign  level  language  programming  capabilities  and 
even  scaled  down  versions  of  data  base  management  systems. 
Tnus,  tne  tecnnology  in  nardware  as  well  as  software 
currently  exists  in  tne  commercial  marKetplace  and  it  is 
possible  that  a  practical  system  can  result  from  efficient 
and  careful  design  and  implementation. 

The  design  tasfc  is  broken  down  into  three  distinct 
parts,  eacn  of  wnicn  is  influenced  Dy  tne  overall  design 
characteristics  and  is  individually  addressed  in  separate 
chapters . 

Tne  design  of  tne  pnysicai  and  logical  data  base  is 
influenced  by  the  desire  to  nave  a  simple  yet  sufficiently 
informative  lata  model,  a  rapid,  real-time  response  ard  a 
restricted,  single  application  system.  The  system  design  is 
influenced  by  tne  microcomputer  environment  wnicn  restricts 
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tne  user  both  in  main  memory  space  and  tne  speed  of  access 
to  secondary  storage  and  the  requirement  for  an  effective 
interactive  system  for  a  non-sopnisticated  user. 

The  design  of  tne  software  to  implement  both  the  data 
oase  and  the  system  is  overwhelmingly  influenced  by  tne 
requirement  that  the  system  support  real-time,  interactive 
processing  of  a  casual,  non-programmer.  Termed  "marine 
proof”  in  the  vernacular,  it  reouires  a  sophisticated 
interface  employing  user  friendly  dialogue  tecnniques  to 
ensure  that  the  operation  is  simple  and  efficient.  For  this 
reason,  and  to  facilitate  system  portability,  a 
microcomputer  compatable  high  level  programming  language  is 
employed  in  implementation. 

In  order  to  Detter  identify  the  user  environment  and  to 
obtain  an  understanding  of  tne  functions  ox'  target 
information,  tne  next  cnapter  describes  tne  mission  and  tne 
current  procedures  or  tne  target  information  section.  It  is 
from  tnis  information  that  tne  system  character  is ti cs  were 
developed  and  the  design  based.  The  information  was  obtained 
from  Navy  and  Marine  Corps  doctrinal  publications  as  well  as 
current  operating  procedures  of  a  Marine  Division  target 
Information  section.  Chapters  III  through  VI  develop  in 
detail,  the  reasons  for  the  parameters  selected  and  the 
decisions  made  in  tne  design  of  tne  overall  system,  tne 
logical  and  pnysical  data  base  and  tne  applications 
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Chapter  VII  addresses  tne  implementation  of  tne  system 
anl  further  implications  of  system  application  in  the  varine 
Corps,  as  well  as  tactical  employment  and  interface  with 
current  anl  future  systems.  Conclusions  and  recommendations 
are  included  in  tne  last  caapter. 

The  source  code  listing,  which  has  been  developed  as  a 
result  of  this  tnesls,  nas  been  pubiisned  as  a  Naval 
Postgraduate  School  tecnnical  report  entitled  A  Prototype 
Program  for  Target  Information  (NPS5id-8l-£fc!7) .  a  data 
dictionary  anl  an  example  of  the  system  interface  are 
included  in  tne  appendices.  A  blbiiograpny  of  applicable 
references  and  a  list  of  abbreviations  used  are  also 
included . 


II.  TARGET  INFORMATION  PROCEDURES  AND  EMPLOYMENT 


A.  GENERAL 

A  precise  understanding  of  the  duties  of  tne  target 
information  officer  and  procedures  used  oy  tae  target 
information  section  is  required  before  detailed  requirements 
for  an  automated  target  information  system  can  oe  statei. 
This  caapter  is  devoted  to  tnat  purpose.  It  discusses  and 
examines  in  detail  tne  doctrinal  duties  and  functions  of  tae 
target  information  officer  and  tne  current  procedures  for 
executing  tnese  functions. 

The  target  information  officer  is  a  member  of  tae  fire 
support  coordination  center  (FSCC).  He  and  nis  staff  provise 
target  information  to  tne  fire  support  coordinator  so  tnat 
effective  employment  of  supporting  arms  is  driven  by  timely 
and  accurate  target  intelligence.  He  worts  directly  vitn  tne 
artillery  representatives,  tne  air  officers  and  tne  naval 
gunfire  support  officers  in  diseminating  appropriate  target 
Information  and  obtaining  surveillance  information.  He 
assigns  battle  damage  assessments  for  attached  targets  and 
further  refines  tne  target  list. 

His  relationsnip  witn  botn  tne  ampniDious  tast  force 
target  intelligence  officer  and  the  landing  force  target 
intelligence  officer  is  extremely  important  since  it  is  from 
these  sources  that  ne  obtains  tne  target  intelligence  wnicn 
generates  tne  target  information. 


B.  DUTIES  OF  THE  TAR&ET  INFORMATION  OFFICER 


Tne  TIO  is  a  Marine  Corps  officer  wno  performs  nis 
duties  uader  tne  staff  cognizance  or  tne  fire  support 
coordinator  (FSC)  and  dories  closely  witn  tne  landing  force 
ODerations  and  intelligence  sections.  Tne  primary  doctrinal 
puolication  for  tne  Marine  Corps  is  Fleet  Marine  For^e 
Manual  (FMFM)  7-1  (Fir°  Support  Coordination'  »nicn  outlines 
nis  duties  as  follows: 

1.  Keeping  tne  FSC  and  tne  otner  fire  support 
representatives  in  tne  FSCC  informed  of  tne  status  of 
targets . 

2.  Ensuring  tnat  pertinent  target  intelligence  is  posted 
on  tne  FSCC  target  and/or  situation  maps. 

3.  Preparing  and  maintaining  target  file  carls. 

4.  Entering  target  attacK  evaluations  and  surveillances  » 
on  tne  target  cards. 

5.  Supervising  the  operation  of  tne  target  information 
section  (TIS)  of  tne  FSCC. 

5.  Preparing  tne  landing  force  list  of  targets  or  tne 
Marine  air-ground  tas!t  force  (MAC-TF)  target  list  for 
promulgation  by  tne  operations  officer.  Tne  FSCC  win 
provide  targets,  to  include  tneir  classification  and 
priorities,  wnicn  are  to  be  included  in  tne  target  list, 
target  bulletins  and/or  lists  of  targets. 

7.  Preparing  and  releasing  target  bulletins  when  control 
of  tne  target  list  nas  been  passed  to  tne  commander 
landing  force  or  wnen  tne  MACTF  is  engaged  in  land 

warfare . 

8.  Keeping  tne  target  intelligence  officer  advised  of 
target  information  available  tnrougn  supporting  arms 
sources. 
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C.  FUNCTION S  OF  THE  TAP.SET  INFORMATION  SECTION 

The  functions  of  the  Tib  are  orientei  to  the 
requirements  of  toe  supporting  arms  (air,  naval  gunfire  and 
artillery)  in  the  preparation  of  fire  support  plans  and  the 
command  requirements  for  target  information.  Tne  TIS  uses 
all  of  the  available  intell ic-ence  gathered  by  the  agencies 
of  tne  ampnibious  tass  force  and  tne  landing  force.  Tnese 
agencies  include  landing  force  and  ampnibious  tasic  force 
target  intelligence  sections  and  intelligence  agencies  of 
the  supporting  arms. 

The  TIS  is  responsible  for  recording  all  target 
information,  analyzing  tnis  target  information,  maintaining 
records  and  masing  recommendations  of  targets  which  are 
appropriate  for  attacir.  FMFM  7-1  lists  tne  following 
functions  of  the  TIS: 

1.  Maintaining  required  target  ana  situation  maps. 

<2.  Maintaining  target  cards  and  target  files,  including 
cross-indexed  flies  of  target  information. 

3.  Consolidating,  evaluating  and  displaying  target 
information. 

4.  Recommending  classification  and  attach  priorities  to 
tne  FSC. 

5.  Collecting  from  ail  agencies  and  sources,  any 
information  pertaining  to  tne  results  of  attacir  on 
targets  by  tne  supporting  arms. 

6.  Consolidating  and  evaluating  results  of  attacks  by 
tne  individual  supporting  arms  and  tne  metnoas  of 
attach,  and  recommending  additional  measures  taat  appear 
necessary  from  tne  overall  results  and  analyses. 
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7.  Coordinating  on  ail  matters  vitn  tne  landing  force 
target  intelligence  officer  and  tne  artillery  unit 
intelligence  officer  for  target  and  counterfire 
information  and  correlation  of  records  and  files. 

B.  Maintaining  current  counterfire  target  lists  to 
include  counter-mortar,  counter-battery  and  3EAD 
(suppression  of  enemy  air  defense)  lists  and  providing 
tnis  information  to  tne  supporting  arms  representatives 
as  well  as  ensuring  dissemination  to  tne  landing  force 
as  a  wnole. 

9.  Preparing  and  disseminating  target  bulletins 
(TaR37L's)  after  control  of  tne  target  list  nas  been 
passed  ashore. 

10.  Maintaining  a  nuclear  and  cnemicai  target  foiaer  to 
assist  in  tne  selection,  evaluation  and  planning  of 
attacic  by  supporting  arms  utilizing  nuclear  and  cnemicai 
munitions. 

Tne  composition  and  organization  of  tne  TIS  varies  witn 
tne  FSCC  level  Dut  typically  at  tne  landing  force  level  it 
consists  of  one  officer  (TIO)  and  from  one  to  tnree  enlisted 
personnel.  Personnel  are  usually  trained  in  target 
intelligence,  supporting  arms  capabilities  and  limitations, 
organization,  fire  support  coordination  principles  and 
communications . 

While  the  functions  and  duties  of  target  information 
personnel  are  determined  by  the  doctrinal  publications,  tne 
actual  procedures  to  accomplish  tnese  functions  will  differ 
slightly  from  one  organization  to  another,  however  tnese 
variations  are  minor. 


D.  TARGET  INFORMATION  RECORD'S  AND  FILES 


Tiie  records  and  files  of  tareet  information  consist 
primarily  of  situation  maps,  target  file  carls,  target  lists 
and  cross-indexing  files  at  tne  landing  force  level.  They 
are  tne  tools  used  to  catalogue,  analyze  and  disseminate 
target  information. 

The  tareet  map  provides  a  visual  reference  of  targets 
appropriate  for  attacic  by  supporting  arms.  Tne  friendly 
situation  map  contains  all  information  pertinent  to 
supporting  arms  operations  and  typically  includes 
objectives,  front  lines,  fire  support  control  measures,  unit 
boundaries  and  unit  locations. 

Tne  bult  of  tne  record  seeping  involves  tne  target  file 

card.  The  file  of  b  by  fc  inch  cards  contains  a  separate 

target  card  for  each  tnown  or  suspected  target  both  by 

tareet  number  and  by  erid  coordinates.  Fleure  1  is  an 

example  of  a  target  card.  Information  appearing  on  tne 

tareet  card  includes  the  foliowine: 

target  symbol  (conventional  map  symbol) 

tareet  number 

target  classification 

attact  priority 

tareet  location  (erld  coordinates) 
tareet  elevation  in  meters 
map  reference 
tareet  description 

assignment  of  supporting  arms  attacs  means 
source  and  date  of  target  information 
photoerapn  number  and  erii  location 
remarks  of  additional  significance 
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The  target  cross-index  file  consists  of  one  card  or  list 
for  each  type  of  target  (e.g.,  counter-oattery,  arncr,  Si'AD, 
fortification,  etc.).  Each  card  or  list  typically  includes 
only  the  tareet  numDer  of  each  tareet,  it's  priority,  the 
recommended  metnol  of  attacic  ana  tne  final  disposition  of 
the  target. 

In  a  typical  ampnitlous  operation,  tne  landing  force 
usually  operates  wita  a  maximum  of  approximately  200-300' 
targets.  Vltn  a  separate  target  card  for  eacn  target  by 
tareet  numDer  as  well  as  oy  arid  coordinate  and  a 
cross-index  card  for  tne  10  to  15  target  types,  tne  target 
file  can  easily  exceed  500  cards.  An  example  of  a  Marine 
division  target  card  file  organization  is  illustrated  in 
figure  2. 


ACTIVE  TARGETS  INACTIVE  TARGETS 


Figure  2.  Target  Card  File  Organization. 


S.  THE  TARGET  LIST 

A  semantic  distinction  must  oe  made  between  toe  "target 
list"  and  t ft e  "list  of  careers”.  The  "tareet  list"  is  a 
collection  of  targets  wnicn  is  maintained  and  promulgated  by 
tfte  senior  echelon  of  command.  There  is  only  one  "tareet 
list".  It  contains  targets  wnicn  are  pertinent  to  tne 

landine  force  as  a  wnole  and  whicn  are  to  be  taiten  under 
attaclc  by  supporting  arms.  A  "list  of  targets"  is  maintained 
at  any  echelon  of  command  and  includes  those  confirmed, 
suspected  or  possible  targets  for  information  and  planning 

purposes  as  well  as  for  possible  attaclc  by  supporting  arms. 
The  "target  list"  is  a  subset  of  the  "list  of  targets". 

Subordinate  units  use  the  target  list  as  their  basic 
source  of  targets  and  also  include  targets  that  nave  a 
significant  but  specific  or  "short-life"  value  to  their 
operations  in  their  unit  list  of  targets.  ^s  an 

illustration,  a  battalion  would  only  include  tnose  targets 
from  tne  landing  force  target  list  wnicn  were  located  in  or 
adjacent  to  their  zone  of  action. 

Targets  can  be  furtner  described  as  active  or  inactive. 
An  active  target  is  one  which  is  on  tne  target  list  or  list 
of  targets  and  presents  a  oonafide  current  or  future  enemy 
capability  to  interfere  with  operations.  An  inactive  target 
is  one  wnicn  nas  been  overrun  by  friendly  forces  or 
destroyed  by  supporting  arms  or  has  shown  no  activity  for 
nours  and  no  damage  assessment  nas  oeen  made,  altnougn  tnese 
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latter  targets  are  Inactivated  vita  caution.  Tne  Inactive 


targets  are  placed.  In  a  deadflle  and  reactivated  if 
necessary.  Fleure  3  depicts  tne  target  list  terminology. 


ACTIVE  TARGETS  INACTIVE  TARGETS 


Figure  3.  Target  List  Terminology. 

F.  TARGET  CLASSIFICATION 

Targets  are  classified  oy  tne  effect  vnlcn  tneir 
ex is tance  or  elimination  may  nave  on  tne  amphibious  tasic 
force  and  by  restrictions  Imposed  by  the  commander  on  tne 
attacic  of  certain  targets. 

The  primary  doctrinal  publication  for  ampniblous 
warfare*  N'rfP  22-2  (Supporting  Arms  in  Ampniblous  Operations) 
list  tne  following  target  classifications: 

Class  A. ..Targets  tnat  threaten  snips,  aircraft, 
minesweeping  and  underwater  demolitions 
operations . 

Class  B.. .Targets  tnat  threaten  assault  forces  in  tne 
snip-to-snore  movement  and  assault  of  tne 
beach . 

Class  C.. .Targets  tnat  tnreaten  or  oppose  landing  force 
operations  afterlanding  or  affect  tne  ability 
of  tne  enemy  to  continue  resistance. 
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Class  D. ..Targets  tnat  will  not  be  fired  on  prior  to 
D-Day . 

Class  E...Tareets  tnat  must  not  be  destroyed  (unless 
specific  orders  for  sucn  destruction  are 

issued  by  the  amnnlblous  tasic  force  or  landtne 
force  commander)  eltner  because  of  probable 
future  use  by  our  own  forces  or  for 

humanitarian  reasons.  These  installations  may 
be  neutralized,  Harassed  or  interdicted  if 
prior  approval  is  obtained  from  the  commander 
lmposin*  tne  restrictions. 

G.  TARGET  PRIORITY 

The  target  Information  officer,  in  coordination  witn  tne 
target  intelligence  officer,  the  fire  support  coordinator 
and  the  supporting  arms  representatives  reviews  and 
recommends  the  assignment  of  attacit  priority.  The  target 
priority  Is  established  to  determine  tne  sequence  of  attach 
and/or  the  effort  to  be  allocated  to  a  elven  target.  The  TIO 
establishes  tne  priority  based  on  the  target's  effect  on  the 
accomplishment  of  the  landing  force  mission  and  its  relative 
importance  as  compared  to  other  targets. 

F!iF?1  ?-l  lists  the  following  target  priorities: 

Priority  I . Targets  capable  of  preventing  the 

execution  of  the  plan  of  action  by  the 
landing  force  and  its  elements. 

Priority  II ...  .Targets  capable  of  immediate  serious 
Interference  with  the  plan  of  action  of  the 
landing  force  and  its  elements. 

Priority  III. .  .Targets  capable  of  ultimate  serious 
interference  with  tne  plan  of  action  of  tne 
landing  force  and  its  elements. 

Priority  17. .. .Targets  capable  of  limited  interference 
with  tne  plan  of  action  of  tne  landing 
force  and  its  elements. 
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H.  THE  TARGET  BULLETIN 


In  order  to  maintain  up-to-date  target  information 
records,  it  is  essential  tnat  reports  of  tne  discovery  of 
new  targets  and  the  analysis  of  supporting  arms  attacks  on 
existing  targets  be  reported  to  tne  appropriate  units.  Tne 
TIO  evaluates  and  consolidates  reports  of  target  information 
and  supporting  arms  battle  damage  assessment  (EDA)  and 
prepares  a  target  bulletin  (TARBUL).  Upon  approval,  it  is 
released  to  interested  commanders  of  nigner,  lower  and 
adjacent  elements  of  tne  ampnibious  tasic  force. 

Tne  TARBUL  is  normally  transmitted  over  existing 
teletype  or  radio  circuits  and  typically  adds  new  targets  to 
tne  target  list  (giving  tne  target  number,  location, 
elevation,  priority,  classification  and  description),  gives 
damage  assessment  to  existing  targets  wnicn  nave  been 
attached  by  supporting  arms,  canceils  targets  from  tne 
target  list  (relegating  tnem  to  tne  deadfile)  and 
reactivates  previously  cancelled  targets.  TARBUL's  are 
serialized  and  issued  on  an  as-needed  basis. 

I.  OPERATIONS  OF  THE  TARGET  INFORMATION  SECTION 

While  tne  target  information  section  is  neaviiy  involved 
in  the  early  pnases  of  the  operation,  tne  most  important 
witn  respect  to  tnis  tnesis  occurs  during  tne  preparation  of 
tne  objective,  ship-to-snore  movement  and  operations  ashore. 
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The  target  list  is  lnitaily  maintained  by  the  SACC 
tareet  intelligence  officer.  Tne  tareet  information  is 
stored  in  a  data  base  of  tne  ASIS  system  and  a  navy  computer 
operator  wording  in  the  SACC  operational  spaces  uses  tne 
QUEST  data  base  query  language  to  access  targets  and  target 
information  from  the  data  base.  Requests  ror  a  target 
listing  and  for  special  purpose  reports  must  oe  composed  in 
tne  query  language  each  time.  Response  to  the  query  is 
displayed  on  a  video  display  unit  in  tne  SACC.  Tne  report 
printouts  are  available  from  a  printer  located  in  the  main 
computer  spaces. 

During  this  period,  the  TIO  is  monitoring  and 
duplicating  tne  target  list  with  the  target  card  files.  It 
typically  is  an  opportunity  for  the  TIS  staff  to  become  very 
familiar  witn  the  target  card  file  procedures,  aitnougn  it 
requires  almost  a  complete  duplication  of  effort  between  tne 
TIC  and  the  TIS. 

When  the  TIS  goes  ashore  with  the  landing  force  FSCC, 
they  obtain  computer  printed  copies  of  the  latest  target 
list  as  a  backup  to  tneir  card  file.  Cnanges  to  tne  target 
list  durine  the  phasine  of  the  TIS  ashore  are  covered  by  a 
TARBQL  issued  by  tne  commander  amphibious  tasic  force. 

Operations  ashore  are  characterized  by  constant 
refinement  of  tne  target  list,  adding  newly  acquired  targets 
and  tne  employment  of  supporting  arms  on  existing  targets. 
Wnen  target  information  is  received,  tne  target  is  plotted 
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on  the  target  map,  a  classification  assigned,  a  target  card 
prepared  and  all  available  information  evaluated.  A  priority 
of  attack  is  assigned  and  a  recommendation  regarding  attack 
by  supporting  arms  is  made.  The  tareet  card  is  then  added  to 
the  target  number  file,  tne  grid  location  file  and  tne 
cross-index  file  if  necessary. 

As  fire  support  missions  are  executed,  tne  TIS  attempts 
to  expedite  the  surveillance  reports  from  the  available  fire 
support  sources.  A  damage  assessment  is  made  based  on  tne 
reported  surveillance.  The  information  is  added  to  the  tact 
of  the  target  card  and  the  target  is  updated  as  required. 
The  primary  sources  of  this  information  are  artillery 
forward  observers,  naval  gunfire  spotters,  forward  air 
controllers  and  liaison  officers. 

New  targets  are  reported  to  the  landing  force  TIS  from 
the  target  information  sections  of  subordinate  units  who 
nave  uncovered  targets  of  sufficient  importance  to  be 
recommended  for  inclusion  on  the  target  list.  Targets  are 
also  received  from  tne  target  intelligence  officer,  tne 
artillery  tar?et  acquisition  battery  and  acoustic  and 
seismic  sensors.  Based  on  tne  accuracy  of  this  information 
(confirmed,  probable,  possible  or  unknown),  a  determination 
is  made  wnetner  to  add  tne  target  to  tne  target  list,  tne 
list  of  targets  or  tne  inactive  file. 
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J.  OPERATIONAL  CHARACTERISTICS 

Tn?  operations  of  tne  TIS  focus  on  two  major  functions; 
tne  maintenance  of  tne  target  card  file  and  tne  grapnical 
representation  of  tne  target  Information  on  tne  target  map. 
Tne  former  function  appears  to  lend  Itself  to  an  effective 
automated  solution.  Tne  following  Items  are  tne  significant 
recurring  requirements  for  maintenance  of  tne  target  card 
file: 


adding  a 
deleting 
changing 
cnanglng 
upda  ting 


target  to  tne  file 
a  target  from  tne  file 
Information  about  a  target  in  tne  file 
tne  status  of  a  target  (active-inactive) 
tne  cross-index  file 


Tne  products  of  tnis  maintenance  are  used  by  tne  TIO  and 

tne  staff  of  tne  FSCC  for  effective  fire  support 

coordination  and  delivery  of  supporting  arms.  An  analysis  of 

tnese  products  indicate  tnat  tne  target  card  file  provides 

tne  following  specific  capabilities: 

provides  all  target  information  for  a  specific  target 

differentiates  between  active  and  inactive  targets 

sorts  or  catalogues  targets  oy  various  parameters  (vnicn 
include  target  no.,  coordirates,  classification, 
priority,  target  type,  supporting  arm  assigned  and 
target  accuracy) 

provides  information  upon  wnicn  to  base  a  TARBUL 
provides  information  for  production  of  tne  target  list 


Any  automated  solution  wnicn  will  be  of  value  to  tne  TIO 
must  be  able  to  perform  tne  requirements  for  maintenance  of 
tne  target  file  quicfcly  and  efficiently.  It  must  provide  tne 
required  end  products  (TARRUL,  target  lists,  specific 
information  about  a  particular  target,  etc.)  as  well  as  tne 
capability  of  providing  specific  target  information  in  a 
manner  and  format  wnicn  can  best  be  utilized  in  tne  FSCC. 

Tne  solution  involves  tne  manipulation  and  management  of 
the  information  contained  on  each  target  card  in  such  a  way 
that  the  speed,  efficiency  and  effectiveness  of  the  TIO  is 
enhanced.  This  must  be  done  in  a  simple,  easy  and 
uncomplicated  manner  and  must  produce  timely  and  accurate 
information. 

K.  SUMMARI 

The  organization  examined  in  this  chapter  is  for  the 
landing  force  target  information  section  (TIS)  (typically  a 
Marine  division  or  a  Marine  ampniDious  brigade)  which 
constitutes  the  most  important  and  most  neaviiy  staffed 
section.  The  TIS  exists  at  regimental  and  battalion  level  as 
well,  but  with  less  formality.  Tfle  card  file  is  not  as 
extensive  (due  to  the  fewer  number  of  targets  in  tne  zone  of 
action  of  a  smaller  unit)  and  tne  target  personnel  usually 
perform  tneir  functions  as  an  additional  ratner  tnan  a 
primary  duty.  The  automated  solution,  nowever,  is  equally 
useful  for  subordinate  units  of  tne  landing  force  in 
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assisting  taem  in  tae  effective  ana  timely  management  cf 
target  information  so  tftat  they  may  effectively  employ  their 
supporting  arms  on  tne  most  important  targets. 

This  chapter  has  provliea  a  review  of  tne  duties  and 
functions  of  tae  target  information  section,  tne  tools  and 
doctrinal  procedures  of  target  information  ana  the 
tecnniques  of  operation.  Additionally  ,  tne  cnaracteri s tl cs 
of  the  tareet  information  function  which  can  be  automated 
nave  been  identified  and  analyzed.  Tne  following  chapter 
uses  this  analysis  to  develop  a  conceptual  framewortr  for  tne 
design  of  tae  target  information  system. 
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III.  SYSTEM  DESIGN  CONSIDERATIONS 


A.  PRIMAP.r  CONSIDERATIONS 

1 .  Sacteround 

Having  defined  tne  current  procedures  for  the  tarset 
information  function,  toe  tasi  now  remains  to  provide  a 
satisfactory  system  design  for  an  automated  solution.  Tne 
design  is  influenced  by  two  important  considerations.  Tne 
nature  of  tne  data  base  is  both  pnysicaily  small  in  size  and 
functionally  restrictive  in  wnat  information  is  required 
from  it.  This,  combined  with  a  requirement  for  a  relatively 
ligntveignt,  portable  and  versatile  computer,  manes  tne 
selection  of  a  microcomputer  an  obvious  and  logical  choice 
for  nardware.  Tnis  confines  tne  solution,  nowever,  to  tne 
microcomputer  environment  which,  while  it  nas  many  desirable 
features,  imposes  a  number  of  major  restrictions  on  tne 
design. 

The  second  major  influence  on  the  design  is  the  impact 
of  numan  engineering  on  tne  user  interface.  Tne  user  is  a 
Marine  in  the  target  information  section  of  the  FSCC  and  the 
functions  ne  performs  are  a  Known  entity.  Tne  system  must 
conform  both  to  his  level  of  training  and  computer 
sopni sti catl on  and  to  tne  functions  and  tastts  ne  performs. 
This  requires  an  interface  whicn  is  user  friendly,  extremely 
easy  to  operate,  sufficiently  sophisticated  to  allow  tne 
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user  to 


perform  the  required  functions  effectively  and 
without  error,  and  capable  of  operating  in  a  real-time, 
interactive  mode. 

Thus,  the  solution  is  confined  by  two  separate 
environments:  tne  microcomputer  environment  and  tne  one 
defined  by  tne  friendly,  sophisticated  user  interface.  They 
jointly  determine  tae  data  structures,  tne  control 
structures,  memory  allocation,  Interactive  complexity  ar.4 
tae  system  modular  design.  Tae  system  must  be  designed  to 
operate  effectively  witnin  tne  restrictions  Imposed  by  tne 
microcomputer  and  tae  parameters  required  by  tne  user 
interface,  in  abstraction  of  these  environments  is  depicted 
in  fieure  4  below. 


Figure  4.  System  Design  Environment. 


2.  Tasits 

A  Key  tasjc  in  tae  system  design  is  tne  definition  of 
tae  usage  factor.  This  is  the  description  of  the  system's 
processing  requirement,  i.e.,  now  tae  lata  is  utilized  by 
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the  system.  This  leads  to  a  top-down  design  methodology  and 
tnree  important  tasns  wnicn  will  determine  tne  design  of  tne 
data  case  as  well  as  the  applications  program.  These  tastes 
are : 

1.  To  identify  all  processing  functions  ana  suoalviae 
these  functions  into  modules  (processes). 

2.  To  determine  all  of  tne  data  that  eacn  process  uses  to 
perform  its  desienated  function. 

3.  To  adequately  describe  tne  system  retrieval 
requirements . 

B.  THE  USER  INTERFACE 

While  chapter  VI  will  address  in  detail  tne  human 
engineering  aspects  of  the  user  interface,  it  is  important 
to  recognize  at  this  point  in  tne  development  of  tne  system 
that  the  user  is  classified  as  a  parametric  user.  Simply 
defined,  tne  parametric  user  is  one  wnose  system  input  is  in 
the  form  of  parameters  only.  He  is  not  a  programmer  altnough 
he  may  nave  programs  available  that  he  can  use.  He  is 
transaction  oriented,  putting  information  into  the  system 
and  retrieving  it  from  tne  system,  generally  requiring  a 
short  response  time.  The  parametric  user  requires  current 
and  timely  data  and  rapid  ana  easy  recovery  from  errors. 

In  addition  to  designing  the  system  to  perform  the  tastes 
and  functions  of  target  information,  it  must  oe  engineered 
for  the  parametric  user  in  order  for  it  to  be  used 
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effectively  and  with  a  decree  of  confidence  because  of  its 
predictable  benavior. 

In  the  design  of  an  interactive  system,  a  very  important 
consideration  is  the  appearance  of  tne  system  to  the  user. 
Use  of  the  technique  cf  interaction  by  anticipation,  that 
is,  anticipating  tne  desires  of  tne  user  ana  presenting  nim 
with  a  corresponding  list  of  options,  allows  tne  user  to 
simplify  his  input  by  selecting  rather  than  specifying  the 
data.  Tne  employment  of  menu  selection  techniques  and 
computer  initiated  dialogue,  important  applications  of 
interaction  by  anticipation,  will  be  used  to  provide  tne 
friendly  man-machine  interface. 

C.  USSR  DESIGN  CRITERIA 

A  particularly  important  aspect  of  tne  design  is  tie 
nature  of  the  constraints  on  the  cognitive  processes  of  the 
user.  One  constraint  is  tne  amount  of  information  tnat  a 
person  can  consider  at  one  time  and  tne  lengtn  of  time  tnat 
tne  information  can  be  retained  in  snort  term  memorv.  Hence, 
the  information  available  from  tne  system  should  be  simple 
enough  to  be  qulcily  and  easily  assimilated. 

The  system  snouid  also  be  fast  enough  so  taat  tne  user 
is  not  distracted  by  tne  loss  of  information  in  nis  snort 
term  memory  due  to  a  slow  response  time.  Tne  system  snouid 
be  able  to  reinforce  user  memory  wnenever  required.  Tnis 
implies  a  user  initiated  request  for  help  to  which  the 


system  must  reply  with  tne  appropriate  information .  An 
important  aspect  in  designing  a  neip  function  is  uniformity 


of  the  command  as  well  as  the  expected  reply. 

A  second  consideration  wnicn  is  important  in  tne  design 
of  interactive  systems  is  the  experience  level  of  the  user. 
The  system  snouli  be  able  to  cater  to  the  novice  user  ar.d 
effectively  direct  his  input  to  perform  the  required  tasKS  . 
It  is  also  important  for  the  system  not  to  ignore  tne 
experienced  user.  The  interface  should  be  aole  to  adapt  to 
tne  needs  and  cnaracteristics  of  its  users  cased  on  tne 
user's  experience. 

The  interface  should  also  De  robust  in  nature.  It  should 
respond  in  an  effective  and  unambiguous  manner  to  any  input 
and  allow  the  user  to  recover  from  simple  errors.  It  should 
discourage  illegal  input  and  guide  tne  user  tc  tne  proper 
inputs  required.  It  should  provide  closure  to  the  user, 
i.e.,  a  logical  completion  to  a  specific  action  within  an 
expected  period  of  time.  It  should  limit  the  user  input  to 
the  necessary  data  and  instructions  sufficient  to  perform 
the  required  tasKS. 

Tnis  is  test  accomplished  for  tne  narametric  user  cy 
interaction  by  anticipation  and  a  restricted  and  unambiguous 
flow  of  man-macnine  communications.  Thus,  communications 
from  the  user  to  the  computer  is  by  discrete  selection  of 
semantically  meaningful  options,  and  from  the  computer  to 
tne  user  by  the  presentation  of  Information  contained  in  tne 
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menu  selection  or  dialogue  frames.  Tnis  will  allow  for  rapid 
and  easy  operations  for  tne  user  and  a  unity  of  lesion  for 
tee  implementor. 

D.  THE  MICROCOMPUTER  ENVIRONMENT 

Microcomputers  impose  a  stringent  set  of  restrictions  on 
tr.e  resources  avallaDle  wnen  implementing  or  executing  a 
program.  These  restrictions  include  tne  small  size  of  main 
memory,  tne  lengtny  access  time  and  small  capacity  of 
secondary  storage  and  tne  low  processing  rate. 

Typically,  microcomputers  are  constructed  witn  32  to  64K 
bytes  of  main  memory.  Wnen  consideration  is  made  for  tne 
ope^atin^  system,  tne  applications  program  and  tne  data 
base,  it  becomes  obvious  tnat  tney  cannot  all  exist  in  main 
memory  at  tne  same  time  and  tne  partitioning  of  memory  and 
tne  arrangement  of  secondary  storage  will  ce  a  Key 
consideration  in  tne  system  design.  Putting  all  tne  data 
into  main  memory  is  not  feasible  because  of  its  size,  yet 
putting  ail  tne  data  in  secondary  storage  results  In 
unacceptable  response  time. 

System  response  time  is  important  to  tne  user.  ?nus, 
tnose  operations  to  wnicn  ne  expects  a  quicK  answer  must  be 
performed  quietly  witn  minimal  access  time.  For  otner 
operations  which  are  logically  time  consuming  to  tne  user 
(for  example,  input  of  a  new  target  into  tne  target  list', 
closure  will  nave  to  be  delayed  (witn  a  computer  advisory 
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message )  vniie  tne  information  is  processed.  Tne  routines  of 


tne  applications  program  must  be  designed  tc  optimize  tne 
accesses  to  secondary  storage,  wnlcn  is  tne  bottleneck  in 
microcomputer  systems. 

E.  FUNCTIONS  OF  THE  SYSTEM 

From  an  analysis  of  tr.e  information  provided  ty  tne 
tarset  card  file  and  tne  functions  and  duties  of  tne  target 
information  section,  a  number  of  major  functions  of  tne 
system  nave  been  identified.  From  tnese  functions,  system 
output  nas  been  identified,  botn  in  tne  form  of  display  on  a 
video  terminal  and  printed  nard  copy.  Tnese  functions  ar.d 
outputs  determine  tne  design  of  tne  data  case,  tne 
applications  program  ar.d  tne  overall  system. 

1 .  Primary  Functions 

Tne  primary  functions  of  tne  system  involve  tne 

manipulation  and  input  of  target  information  into  tne  proper 

storage  formats.  Tnese  functions  include: 

Add  a  target  to  tne  file 
Delete  a  target  from  tne  file 
Cnanee  information  about  a  target 
Cnange  target  status  (active/inactive) 

Copy  data  base  to  a  backup  file 
Initialize  the  target  file  data  base 
Display  certain  target  information 
Print  certain  target  information 

These  last  two  functions  could  become  very  extensive 
operations  if  desired.  However,  a  carefully  restrictive 
design  of  tne  data  base  model  and  a  desire  to  limit  tne 
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semantic  options  of  the  parametric  user  to  certain, 
defined  operations,  has  reduced  tnerr  to  maaa*aoie  yet  fuiiy 
appilcatle  functions. 

2.  Display  Options 

Tne  CRT  (catnode  ray  tv.ee)  device  •ill  te  tne 
primary  user  interface  mechanism.  ^ost  of  tne  information 
input  and  extracted  from  tne  system  win  ee  performed  via 
tne  CRT.  Tne  Interactive  queries  to  tne  data  ease  will 
result  ir.  tne  following  display  options: 

Display  a  complete  target  card 
Display  a  list  of  all  the  active  targets 
Display  a  list  of  all  tne  inactive  targets 
Display  tne  target  list 

Display  tne  information  for  tne  next  TAR2UL 
Display  a  list  of  targets  by  specific  parameters ) 

Display  parameter  status  for  tne  active  targets 

The  parameters  indicated  above  are  selected  categories 
of  target  information  obtained  from  tne  target  card  wnicn 
are  tne  typical  parameters  for  special  listings  and  tne 
cross-index  files.  It  represents  a  selection  of  those  items 
of  information  which  can  be  most  effectively  utilized  by  the 
?SC  and  tne  supporting  arms  representatives  in  tne  f’SCC. 
These  parameters  include: 
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Target  Priority 
Target  Classification 
Target  Numter 
Target  Status 
Target  Type 

Supporting  Arm  Assigned 
Attached  Target 
Tareet  Information  Accuracy 
3rid  Coordinates 

i.  Print  Options 

Hard  copy  of  tne  target  information  is  a  definite 
requirement  for  operations  at  any  level  FSCC.  Tne  system 
•#111  nave  tne  capability  to  print  the  target  list  and  tne 
list  of  targets.  The  production  of  a  TAR3UI  based  on  tne 
transactions  with  tne  data  base  sin~e  tne  last  published 
TAR3UL  will  provide  a  significant  nelp  to  tne  TIO. 

The  tareet  listines  by  specific  parameter  (for  example, 
a  list  of  all  active  targets,  class  C,  priority  II,  of 
target  type  "SBAD”  assigned  to  artillery)  is  a  requirement 
tnat  will  be  applicable  to  all  members  of  tne  FSCC.  Tne 
system  will  also  nave  the  capability  to  print  a  ~opy  of  the 
target  card  for  dissemination  to  otner  agencies  as  well  as 
to  provide  a  manual  backup  in  case  of  power  or  computer 
failure. 

F.  SUGARY 

This  chapter  alone  with  tne  preceedine  cnapter  nas 
defined  tne  doctrinal  functions  of  target  information, 
determined  tne  environment  for  tne  automated  solution  of 
tnese  functions  and  presented  tne  system  requirements  for 
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tnls  solution.  These  cnapters  form  a  necessary  foundation 
for  tne  subsequent  cnaoters  wnich  address  tne  specific 
details  of  tne  system  and  tne  data  Case  design.  Tne  next 
cnapter  addresses  tne  actual  system  design  and  includes  tne 
nardvare  and  software  selection  and  a  top-down,  modular 
approach.  It  contains  important  decisions  concerning  tne 
data  base  waicn  are  developed  in  greater  detail  in  cnapter 
7. 
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IV 


SYSTEM  DESIGN 


A.  CONCEPTUAL  SYSTEM  DESIGN 

1.  Generality  of  Approach 

In  talcing  a  top-down  classic  approacn  to  tne  design 
or  the  target  information  system,  the  initial  design  does 
not  consider  tne  restrictions  imposed  oy  tne  operating 
environment.  This  is  done  for  two  reasons.  First,  tr.e 
conceptual  design  presents  a  simple,  traditional,  straight 
forward  solution  wnicn  can,  in  concept,  ce  readily 
Implemented.  Second,  it  provides  tne  basis  upon  wnicn 
modification  and  adjustment  may  be  performed  to  fit  tne 
simple  solution  into  tne  restrictive  environment.  Tne  size 
of  tne  system,  tne  interface  requirements,  ana  tne 
restrictive  data  base  view  will  cause  tne  conceptual  aesign 
to  be  tailored  and  modified  to  operate  in  tne  selective 
environment. 

2.  Data  Base  Considerations 

Tne  target  card  data  provides  tne  entities  (or 
records),  attributes  and  relationships  of  a  data  tase 
system.  Tne  controlling  software,  tne  data  base  management 
system  (DBMS),  would  normally  contain  language  facilities 
for  defining  tne  data  Dase,  for  manipulating  tne  data  base 
information  and  for  obtaining  information  from  tne  data 
base.  Tnis  last  facility,  tne  nign  level  query  language, 
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allows  tne  user  to  manage  t he  Information  of  tne  data  Case 
and  perform  tne  required  operational  functions. 

The  data  base  concept  enaoies  tne  user  to  store  tne  lata 
in  space  saving  and  efficient  ways.  Redundancy  of  data  can 
be  eliminated  and  data  items  deleted  which  can  De  implicitly 
derived  from  otner  data  items.  Tne  system  allows 
construction  of  different  views  of  tne  lata  so  tnat 
different  users  can  perform  different  functions  on  tne  same 
type  of  data.  Applications  programming  is  simplified  since 
it  only  needs  to  specify  parameters  to  tne  DBMS  wnicn 
locates  and  fetcnes  tne  data. 

Tnus,  tne  design  of  tne  data  oase  portion  of  tne 
conceptual  system  will  require  tne  construction  of  tne 
logical  and  tne  pnyslcal  view  of  tne  information,  definition 
of  tne  information  in  terms  of  tne  data  base  definition  ar.d 
manipulation  languages  and  providing  a  DBMS  witn  a  facility 
for  query  lanrua^e  translation  to  operate  on  tne  data  base. 

3.  Applications  Program  Considerations 

Tne  user  environment  remains  as  defined,  a  friendly, 
sopnisticated  interactive  man-macnine  interface.  Tne 
applications  program  must  interact  witn  the  user  ana  witn 
tne  DBMS.  Tne  use  of  a  query  language  for  tne  parametric 
user  would  require  tne  user  to  learn  tne  data  base  query 
language.  Alternatively, a  collection  of  query  language 
statements  could  be  Imbedded  in  tne  applications  program  and 
selected  by  tne  user  utilizing  tne  menu  selection  interface. 

50 


Tnese  statements  would  interact  directly  witn  t.ne  L'BMS. 
Additionally,  tne  cost  lan^ua^e  could  be  extended  to  enable 
it  to  pass  information  to  tne  DBMS  in  tne  form  of  a 
procedure  call. 

Tne  requirement  for  menus,  nelp  functions  and  system 
explanations  could  De  effectively  solved  by  tne  use  of 
user-oriented  utility  modules  wnicn  could  be  accessed  as 
needed.  Tne  basic  conceptual  system  design  derived  from  a 
top-down  view  of  tne  target  information  system  taste  is 
depicted  in  figure  5.  Tnis  basic  design  will  be  refined  to 
fit  witnin  tne  solution  environment. 


Figure  5.  Design  of  tne  Conceptual  Model. 

B.  PRELIMINARY  CONSIDERATIONS  FOR  SYSTEM  DESIGN 

With  tne  basic  framework  laid  out  by  tne  conceptual 
model,  tne  tasir  now  becomes  one  of  attempting  to  insert  tnis 
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classic  approacn  design  into  the  restricted  environment  of 
tne  microcomputer.  This  reouires  a  high  de^r^e  of 
specificitv  in  order  to  identify  tne  tools  to  be  employed  in 
tne  implementation  and  tne  methodology  of  employing  tnose 
tools.  Tne  target  macnine  must  be  identified  to  precisely 
define  tne  microcomputer  constraints.  Tne  data  bas=  model 
and  Its  physical  ana  logical  organization  must  be  defined, 
tne  applications  program  functions  and  tasK  flow  analysis 
must  be  determined  and  tne  target  programming  language  must 
be  identified. 

C.  HARDWARE  SELECTION 

The  selection  of  tne  system  nardware  was  driven  by  tnree 
considerations.  First,  it  had  to  be  a  commercially 
available,  typically  configured  microcomputer.  Sucn 
generality  is  needed  if  tee  system  was  to  be  transportable 
to  otner  microcomputers.  In  tne  searen  for  a  typical 
microcomputer,  an  effort  was  made  to  avoid  tne  home  or 
personal  computers  wnicn,  while  small,  easily  transportable 
and  Inexpensive,  possess  neither  the  processing  power  nor 
tne  virtual  memory  capacity  needed  for  tne  system. 

The  second  consideration  was  for  a  computer  that 
possessed  acceptable  size  and  weignt  characteristics  for 
transportability,  had  a  compact  configuration,  was  generally 
rugged  for  a  commercial  product  and  nad  sufficient 
processing  capacity. 
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The  thirl  consideration  was  aval ia Oil ity.  Tr.e  ALTOS 
ACS-9000  is  a  representative  of  micro-systems  commercially 
available,  anl  was  selected  for  use  in  tnis  worn.  Tne  ALTOS 
microcomputer  conforms  well  to  the  desired  computer 
characteristics .  LCDR  D.  L.  Smith  in  his  thesis  entitled 
Method  to  Evaluate  Microcomputers  for  Non-tactical  Shipboard 
rJse  cited  the  ALTOS  as  one  of  the  top  four  microcomputer 
systems  evaluated  and  found  it  suitable  for  use  on  U.S.  Navy 
ships. 

Tne  ALTOS  ACS-9000-1  is  a  single  board  Z-90A  basea 
microprocessor  with  54E  bytes  of  random  access  memory  and 
two  Snu^art  SA-900/901  eignt  incn,  single  side  floppy 
diskette  drives  contained  within  the  16  by  7  by  17  inch 
compartment.  It  requires  a  CRT  for  input/output  and  supports 
129  characters  of  upper  and  lower  case  ASCII  with  90 
characters  per  line  on  a  24  line  video  display.  Tne  computer 
weighs  approximately  35  pounds,  nas  a  forced  cooling1  system, 
utilizes  standard  115  volt  electric  power  with  a  cattery 
bactup  and  operates  within  a  temperature  range  of  32-105 
degrees  farenneit  and  a  humidity  range  of  10-90  percent. 

The  two  floppy  diskettes  with  tne  IEM  3740  single 
density  format  and  tne  64X  of  main  memory  gives  a  total 
memory  space  of  575K  bytes.  The  high  level  language  support 
for  tne  ALTOS  includes  tne  CP/M  operating  system,  .basic, 
FORTRAN,  Pascal,  PL/I-90,  APL,  LISP,  COBOL  and  the  Micro 
Data  Base  Systems  DBMS  for  a  microcomputer. 
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D.  PROCRAM^In:}  LANG'JASS  selection 


The  selection  of  a  programming  language  was  influenced 
by  tnree  major  considerations.  First,  tne  nardware  selected 
and  the  availability  of  assemblers,  interpreters  and 
compilers  to  support  a  programming  project  on  tnis  nardware 
narrowed  tne  field  considerably.  Second,  there  was  a  desire 
to  use  a  language  wnicn  is  relatively  self-explanatory, 
self-documenting  and  transportable.  And  finally,  tne 
language  would  nave  to  support  a  robust,  user-oriented 
interactive  program. 

Of  the  available  languages,  Pascal  was  selected  for  a 
number  of  reasons.  It  has  features  wnicn  mate  it  readily 
useable  for  systems  and  applications  programming  in  that  it 
is  "strongly  typed”,  requiring  explicit  data  declaration.  It 
forces  the  data  base  to  be  completely  designed  before  tne 
source  program  is  written. 

Pascal's  structure  encourages  modularity  as  well  as 
top-down  design  and  implementation.  It  is  a  relatively 
simple  language  and  is  tne  oasis  for  tne  proposed  Department 
of  Defense  standard  nlgn  order  programming  language,  Ada. 
The  most  popular  version  of  Pascal  for  microcomputer  use  is 
tne  University  of  California  at  San  Diego  (UCSD)  version 
developed  by  the  University's  Institute  for  Information 
Systems. 

The  UCSD  (Mini-Microcomputer)  Pascal  version  1.4b  is  a 
system  intended  to  run  on  a  stand-alone  mini  or 


microcomputer.  It  is  nigniy  macnine  independent  since  it 
runs  on  a  pseud o-macnine  interpreter.  Tne  system  contains  a 
compiler,  linter,  screen  oriented  editor  and  an  operating 
system  wnicn  are  compatible  wi  tn  Z-?tf  microprocessors  tnat 
operate  under  tne  Digital  Researcn  CP/V  operating  system. 

Because  of  tne  microcomputer  environment,  tnere  are  a 
number  of  differences  between  tne  UCSD  Pascal  and  tne 
standard  version  of  Pascal  as  defined  by  Jensen  and  Wlrtn. 
Particularly  nelpfui  are  a  number  of  string  intrinsics, 
random  access  of  files  by  a  SEEK  command,  file  nandling 
commands  and  seement  procedures.  Tne  seement  procedure 
capability,  for  example,  enables  tne  user  to  segment  tne 
applications  program  into  a  main  program  and  up  to  six 
procedure  modules  wnicn  are  retrieved  from  secondary  storage 
when  called.  Tnis  allows  a  laree  portion  of  the  program 
object  code  to  reside  on  disfc  wnen  not  needed,  tnus, 
increasing  tne  size  of  main  memory  for  computation  and 
operating  system  functions. 

E.  DATA  BASE  CONSIDERATIONS 

Tne  design  of  tne  pnyslcal  and  logical  data  base  is 
addressed  in  detail  in  tne  next  cnapter  ana,  accordingly, 
tnis  section  will  address  only  tnose  items  of  Importance  to 
tne  system  design.  In  tnat  tne  user  view  of  tne  scnema  and 
tne  conceptual  view  of  tne  scnema  are  identical,  and  because 
tnere  is  no  requirement  for  an  integrated  data  base,  tne 
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traditional  data  models  (relational,  hierarchial  and 
network)  will  not  be  employed. 

Consideration  was  given  to  using  existing  DBMS  systems 
for  tne  target  information  system  but  tney  were  rejected  for 
essentially  two  reasons.  First,  tne  target  information 
system  is  a  restricted,  single  application  data  base,  it  is 
sufficiently  restricted  tnat  a  general  purpose, 
multi-faceted  data  base  management  system  is  not  required. 
Second,  tae  use  of  a  DBMS  query  language  was  considered  botn 
time  consuming  and  difficult  to  learn  for  tne  system  user 
and  unnecessarily  complicated  tne  interface.  Tnis  is 
especially  true  because  tne  system  is  designed  to  limit  tne 
type  of  queries  allowed  on  tne  data  base. 

By  extending  tne  nost  language  from  tne  applications 
program  to  tne  lata  base,  data  independence  is  lost. 
However,  since  tne  system  will  not  allow  tne  user  to  access 
tne  data  base  in  any  way  otner  tnan  tnat  specifically 
allowed  by  tne  system  interface  design  and  since  tnere  is 
only  one  view  of  tne  lata,  tnis  does  not  present  a  problem. 

Tne  lata  base  will  consist  of  two  files.  Tne  first  is  a 
flat,  relational  model  representation  witn  tne  target  as  a 
single  record  and  the  target  information  pertinent  to  that 
specific  target  as  tne  attributes  of  tnat  record.  All  of  tne 
active  and  Inactive  targets  will  be  contained  in  this  main 
target  file.  Tne  second  file  will  be  tne  data  base  query 
file  consisting  of  tne  primary  and  secondary  jceys  for  each 
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target.  Tne  standard  system  queries  will  return  information 
in  the  tareet  list  format  and  will  ootain  all  tne  necessary 
data  from  tne  lata  ease  query  file. 

This  partition  of  data  base  files  increases  tne  data 
redundancy  of  tne  system  since  all  tne  data  in  tne  query 
file  is  duplicated  in  tne  main  file.  However,  this  is  done 
to  improve  tne  system  response  time  to  user  queries  ov 
greatly  reducing  tne  disk  accesses  that  would  nave  been 
required  to  process  tne  main  file.  This  tradeoff  is  made  in 
favor  of  tne  user  Interface  and  at  tne  expense  of  additional 
storage  space  and  increased  program  complexity. 

Tne  secondary  keys  used  to  process  tne  target 
information  queries  (priority,  classification,  type,  etc.) 
are  contained  in  tne  in  tne  data  base  query  file.  An  index 
file  containing  tne  addresses  of  the  tareet  records  is 
constructed  in  main  memory  at  tne  beginning  of  tne  program, 
thus,  eliminatine  the  need  for  a  separate  record  address 
file  and  reducing  tne  number  of  disk  seeks  required  to 
access  a  record  from  tne  main  tareet  file.  Vere  tnis  not 
done,  tne  system  would  nave  to  access  an  address  index  file 
in  secondary  storaee  to  obtain  the  address  and  tnen  access 
tne  record  in  tne  main  target  file  in  secondary  storage  to 
obtain  tne  record.  Having  tne  index  in  main  memory  requires 
only  one  access  to  tne  disk,  tne  access  for  tne  actual 
record . 
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The  modules  of  the  applications  program  directly 
interface  to  tne  data  base  files  accessing,  manipulating  ar.d 
rewriting  the  data  as  necessary.  The  system  performs  data 
base  operations,  not  data  case  management  and  is  an 
extension  of  tie  host  language. 

?.  USSR  INTERFACE  CONSIDERATIONS 

In  the  preceding  chapter,  tne  user  interface  was  defined 
and  the  general  requirements  determined.  These  reauirements 
are  now  translated  into  specific  design  parameters  for  tne 
target  information  system.  Additional  discussion  of  the  user 
interface  and  details  of  tne  dialogue  techniques  used  are 
presented  in  depth  in  chapter  VI. 

The  user  interface  is  caaracteri zed  by  four  major 
attributes: 

1.  Ail  communications  between  tne  user  and  tne  computer  is 
through  menus,  if  a  simple  command  is  adequate,  or  tnrougn 
interactive  computer  initiated  dialogue  for  more  extensive 
data  entry. 

2.  Extensive  help  is  available  at  all  times.  This  help 
includes  explanations  of  tne  options  available,  tne  format 
of  the  required  input  and  examples  of  the  correct  input. 

3.  The  display  processing  time  is  as  snort  as  possible  to 
remain  within  the  constraints  of  short  term  memory 
retention  and  logical  closure. 
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4.  Tne  user  is  restricted  to  tne  system  defined  options 
for  data  input  and  data  and  information  retrieval.  Tnus , 
only  tnose  procedures  defined  oy  tne  system  tnrou*n  tne 
menus  and  tne  dialogues  can  be  used. 

G.  APPLICATIONS  PROGRAM  CONSIDERATIONS 

Tne  metnodoiogy  of  applications  program  design 
encompasses  tnree  separate  but  interrelated  areas,  earn  of 
whicn  is  continually  influenced  by  tne  system  deslen 
environment.  Taese  areas  are  semantic  structure  design, 
syntactic  structure  design  and  software  design. 

In  tne  top-down  semantic  design  stage,  tne  system  goals 
were  translated  into  ttte  applications  program  *oais  and  tne 
system  functions  and  requirements  were  determined, 
categorized  and  prioritized.  Tne  tasic  flow  of  tne  system  was 
analyzed  and  alternatives  developed  and  compared.  Tne 
selection  of  tne  most  effective  solution  to  eacn  of  tne 
problems  posed  by  tne  system  requirements  was  expressed  as  a 
functional  module.  Tnis  module  was  tnen  further  brolcen  down 
into  smaller  modules  wnicn  address  particular  parts  of  tne 
functional  requirement.  Tne  data  structures  and  control 
structures  were  tnen  determined  wnicn  best  enable  tnese 
modules  to  perform  tne  required  functions. 

Tne  design  of  tne  syntactic  structures  paralleled  tnat 
of  tne  semantic  structures  and  involved  tne  determination  of 
display  formats  from  a  comparison  of  different  approacnes  to 


the  user  Interface.  In  addition  to  display  formats,  system 
response  formats,  error  dlagnos tl cs ,  user  aids  and  help 
facilities  were  also  specified. 

The  software  was  designed  in  a  top-down  modular  fasnion 
and  best  use  was  made  of  tne  facilities  of  tne  UCSD  Pascal 
system  segment  procedures  as  well  as  the  structured  approach 
provided  by  the  Pascal  language. 

Tne  target  information  system  applications  program 
consists  of  six  major  modules.  The  primary  module  is  the 
Interface  module.  It  acts  as  tne  executive  of  tne  program 
and  controls  the  interaction  of  tne  user  input/output,  the 
data  base  operations  and  tne  segment  procedures. 

The  remaining  modules  are  segment  procedures,  that  is, 
they  reside  in  secondary  storage  until  called  into  main 
memory  by  a  procedure  invocation.  Upon  invocation,  tney  are 
read  into  main  memory  and  computation  continues,  irfhen 
control  is  returned  to  tne  calling  procedure  (in  tnis  case, 
the  Interface  module),  the  memory  space  is  deallocated.  The 
UCSD  system  allows  up  to  six  of  tnese  segment  procedures  and 
permits  them  to  be  nested  in  order  to  further  reduce  the 
amount  of  code  necessary  in  memory. 

Tne  Initialize  module  is  used  wnen  tne  data  base  system 
is  initialized  and  a  new  target  file  is  created.  The  Query 
module  contains  tne  menus  and  tne  semantics  for  tne  system 
queries  to  the  data  base  query  file.  It  is  used  only  when 
target  information  by  specific  parameter  is  desired  by  tne 
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TID.  A  Utility  module  contains  a  number  of  Housekeeping 
routines  for  constructing  tne  TARBUL,  determining  target 
file  status,  copying  tne  data  base  to  another  diskette, 
printing  target  listings  and  otner  functions. 

Tne  Target  module  is  tne  major  segment  procedure  and  is 
used  for  addin*,  deleting  and  changine  targets  in  tne  main 
target  file.  It  also  updates  tne  data  base  query  file  and  if 
necessary,  tne  TARBUL  file.  The  Inform  module  contains 
user-oriented  information  concerning  doctrinal  terminology, 
systems  instructions,  version  information  and  tactical 
guidelines. 

The  target  Information  system  design  is  illustrated  in 
figure  6.  Because  much  of  the  design  was  influenced  by  the 
microcomputer  constraint,  tne  amount  of  object  code  resident 
in  memory  at  one  time  has  been  minimized.  The  illustration 
in  figure  ?  snows  tne  expected  allocation  of  secondary  and 
main  memory  for  the  system,  (see  pages  64  and  65^ 

H.  SECURITY  AMD  INTEGRITY 

Security  for  the  system  is  essentially 
non-dlscretionary .  Tne  system  is  secure  because  it  is 
located  in  a  secure  area  (the  PSCC  is  usually  a  restricted, 
controlled  access  area  within  a  secure  perimeter).  Tne 
targets  contained  in  the  list  of  targets  are  typically 
classified  confidential  and,  tnerefore,  tne  diskettes  would 
be  considered  classified  matter.  Thus,  tne  usual  precautions 
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and  practices  for  tne  security  of  classified  material  are 
sufficient  for  tne  system. 

As  a  further  safeguard  and  security  feature,  tne  system 
will  nave  a  user  password  wnich  will  allow  only  bonaflde 
Individuals  to  access  tne  data  base  of  targets.  Input  or  an 
improper  or  erroneous  password  will  Keep  tne  user  in  tne 
outer  ed*e  of  tne  Interface  module  and  prevent  opening  tne 
data  base  index  file  without  wnicn,  tne  data  cannot  be 
accessed.  The  Utility  module  has  a  subroutine  which  allows 
tne  user  to  specify  nis  own  passwords. 

The  target  Information  system  will  reside  on  an  eigat 
lncn  floppy  diskette  wnicn  will  contain  tne  Pascal  operating 
system  and  the  object  code  of  tne  applications  program.  Tne 
source  code,  editor  and  compiler  will  be  removed  from  tne 
diskette  to  prevent  any  user  from  modifying  or  changing  any 
part  of  tne  system.  Tne  user  can  only  cnange  tne  password 
and  the  target  information. 

Upon  activation  of  the  system,  a  user  advisory  message 
will  be  printed  on  the  CRT  screen  informing  tne  user  of  nis 
responsibility  to  safeguard  the  classified  information.  All 
of  the  printed  output  of  tne  system  will  contain 
confidential  maricin*s  on  eacn  pa*e  as  required  by  current 
security  regulations. 

Nuclear  and  chemical  target  information  and  analysis 
will  be  excluded  from  tne  target  information  system  and 
processed  in  accordance  with  current  procedures.  This  is 


done  primarily  because  tnese  targets  require  special 
techniques  for  analysis,  are  typically  of  a  higher 
classification  tnan  confidential  and  are  of  sucn  a  deeree  of 
sensitivity  tnat  special  nandilne  Is  usually  required. 

I.  TRANSITION 

A  itey  element  of  tne  system  Is  tne  pnysical  am  logical 
desien  of  tfte  data  base.  Since  tfte  system  is  functionally 
restrictive,  tne  data  base  nas  been  designed  to  provide 
optimal  performance  to  tne  user.  Tnis  nas  resulted  In  desien 
parameters  vnicn  are  explained  in  deptn  In  tne  next  cnapter. 
Tne  chapter  develops  some  of  tne  Important  considerations  of 
data  base  tecnnology  and  tne  metnodology  of  data  case 
selection  and  file  determination.  Tnese  techniques  were  used 
to  design  tne  logical  target  information  record. 

System  and  environmental  requirements  Impact 
significantly  on  tne  pnysical  data  base  design  and  a  number 
of  alternatives  are  presented  and  evaluated.  Tne  pnysical 
record  desien  as  well  as  the  Inverted  file  indices  are 
described  In  detail  and  provide  a  Justification  for  tne 
system  design  presented  In  tnis  cnapter. 


63 


Cl SPLAT 


l:.f  Crv 
vOi/JL  i 


Jisrure  6 


Target  Information  System  Cesi# 


interlace 
''cauls 
lfc  5 


D  r*  />  o 

h,  A  Sj 


sword 

ile 


a  o  fi 


7.  DA.TI  BASE  DESIGN 


A.  PRELIMIN ART  DESIGN  PROCESS 

Before  tne  design  of  tne  pnyslcai  ana  tne  logical  data 
base  can  proceed,  tnere  are  certain  ground  rules  and  design 
criteria  tnat  must  be  established.  Data  base  technology  has 
become  more  formalized  in  the  past  ten  years  with  general 
acceptance  of  three  major  data  models,  the  relational,  the 
hlerarcnial  and  tne  network  or  CODASTL.  The  tasic  now  becomes 
one  of  determining  the  content  of  the  target  information 
data  base  and  wnicn  of  tne  major  data  models  is  most 
appropriate  for  the  detailed  design  of  the  logical  and 
physical  data  base. 

1 .  Data  Base  Concepts 

Perhaps  the  initial  starting  point  should  be  a 
definition  of  tne  data  base.  One  of  tne  most  often  quoted 
sources  is  James  Martin's  from  his  Computer  Data-base 
Organization : 

A  data  base  may  be  defined  as  a  collection  of 
interrelated  data  stored  toeetner  with  as  little 
redundancy  as  posslDle  to  serve  one  or  more  applications 
in  an  optimal  fasnion;  the  data  are  stored  so  tnat  they 
are  Independent  of  programs  which  use  the  data." 

It  is  important  to  dlstinguisn  between  a  data  base 
system  and  a  file  system.  A  file  system  organizes  the  data 
storage  capability  wnicn  is  provided  by  tne  hardware  or 
operating  system  software.  The  hardware  is  partitioned  Into 
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flies  wnich  are  associated  with  a  particular  user  or  for  a 
specific  purpose.  Operations  on  one  file  are  done  in 
isolation  from  tne  otner  files  (or  otner  users).  Tnus,  to 
access  tne  same  information  from  many  similar  files  may 
require  as  many  separate  operations  as  tnere  are  files. 

A  data  base  system,  on  tne  otner  hand,  organizes  tne 
file  storage  capability  which  is  provided  by  the  file 
system.  Tne  relationship  between  elements  or  entities  of  tne 
file  are  made  accessible  to  the  system.  Tne  user  *ains 
access  to  all  of  tne  data  because  it  is  now  available 
through  relationships  to  other  data.  Additionally,  different 
users  can  access  the  same  data  and  snare  it. 

Access  to  the  data  base  is  provided  by  a  lata  language, 
a  set  of  operations  which  permit  access  to  the  data  that  has 
been  organized  by  a  lata  model.  Data  base  management  systems 
are  generally  classified  by  tne  way  they  provide  access  to 
the  data.  A  self-contained  system  provides  all  the 
capabilities  and  required  services  by  itself,  typically, 
throueh  a  query  lansuaee.  Host-based  systems  carry  out  the 
retrieval  and  update  functions  only  and  deliver  tne  lata  on 
request  to  programs  written  in  the  host  system  lan*ua*e. 
Occasslonally,  tne  nost  language  is  extended  to  operate 
directly  with  the  data  base,  but  usually  with  a  loss  of  data 
independence . 
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Data  Base  Terminology 

Each  of  the  major  data  models  refers  to  concepts  of 


data  In  slightly  different  terminology.  For  example,  tne 
physical  record  type  "target"  consisting  of  target  number, 
grid  location,  altitude,  priority,  classification  and 
description  Is  called  an  entity  by  one  model,  a  segment  or  a 
logical  record  by  another  and  a  tuple  by  tne  third.  To  avoid 
confusion  and  misunderstanding,  a  set  of  terms  which  are 
partially  intuitive  in  nature  and  generally  from  the 
relational  model  will  be  used.  These  terms,  their 
definitions  and  an  example  from  tne  target  information 
system  are  as  follows: 

Hecord . a  eroup  of  one  or  more  data  items  or  attributes 

which  corresponds  to  a  simple  record  or  entity  [a 
tareet] 

Attribute . tne  smallest  unit  of  data,  a  data  field  with 

a  certain  value  [target  AA0001  with  the  "oriority" 
attribute  nas  value  I I I J 

Relationship . the  connector  between  individual  records 

of  the  same  type  or  groups  of  records  of  different 
types  [tne  list  of  targets] 

Relation. ....  the  set  of  all  records  of  a  «iven  type  l the 
list  of  targets] 
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Degree . tne  number  of  attributes  in  a  record  (.for  a 

record  with  target  number,  location,  priority, 
classification  and  description,  the  degree  of  the 
record  would  be  5  J 

Cardinality . tne  number  of  records  in  a  relation  [tne 

number  of  targets  in  the  system] 

Domain . the  set  of  all  possible  values  for  an  attribute 

[priority  has  domain  I,  II,  111,17] 

Primary  sey . one  or  more  attributes  of  a  record  wnose 

value  uniquely  identifies  the  record  [target  number 
AA004S] 

Secondary  gey . an  attribute  wnicn  may  or  may  not 

uniquely  identify  the  record  but  whicn  defines  a  set 
on  the  record  [all  priority  I  targets] 

Schema . the  structure  of  the  entire  data  base 

Subschema . that  portion  of  tne  schema  viewed  by  a 

particular  user  or  group  of  users 

Plat  file . a  relation  in  normal  form:  a  single  level 

record  array  with  only  one  record  type 

3.  File  Determination 

Tne  total  volume  of  data  in  tne  target  information 
system  must  be  viewed  with  the  objective  of  splitting  It 
into  smaller  units  that  may  oe  considered  tne  basis  for 
organizing  the  data  base  file.  Having  already  determined  the 
system  functions  from  cnapters  III  and  17,  tne  data  objects 
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and  the  relationships  to  perform  these  functions  must  be 
determined  and  organized.  Tne  results  of  tnis  organization 
will  become  tne  criteria  for  tne  modular  design  of  tne 
applications  program. 

William  Bouse  in  Data  Base  Management  provides  an 
excellent  methodolo/ey  for  file  determination.  Data  splitting 
separates  tne  system  Information  into  subsets  which  can  be 
dealt  with  more  or  less  independently  and  pernaps  made  an 
independent  file  of  tne  data  base.  Record  design  determines 
tne  format  of  tne  content  to  appear  in  eacn  record  and  tne 
modes  of  indexing  in  order  to  establisn  the  index  data  that 
must  be  present. 

Tolume  analysis  estimates  tne  size  of  tne  individual 
record  and  tne  size  of  tne  record's  relation  (cardinality). 
The  physical  distribution  of  tne  number  of  records  in  eacn 
file  must  also  be  taken  into  account  to  determine  tne  space 
management  requirements.  Activity  analysis  determines  the 
frequency  of  reference  and  estimates  tne  total  activity  for 
the  records  of  eacn  file.  It  is  tnis  analysis  tnat  is 
essential  to  tne  question  of  file  design  and  one  of  tne  key 
considerations  in  tne  microcomputer  environment, 
particularly  tne  access  bottleneck  to  secondary  storage. 

File  design  is  dependent  upon  tne  record  structure, 
pnysical  distribution  of  tne  records  in  tne  storage  device 
and  tne  indexing  method  employed  in  referencing  tne  record. 
Tne  critical  issue  for  file  design  is  its  performance. 


4.  File  Performance 

There  are  a  number  of  criteria  which  must  be 
considered  wnen  estimating  tne  performance  of  tne  file 
design.  There  will  inevitably  be  a  trade  off  between  storage 
space  and  processing  speed.  There  are  instances  wnen  tne 
rapidity  of  access  to  information  in  the  data  base  is  more 
important  tnan  saving  or  optimally  utilizing  tne  secondary 
storage  space.  This  may  mean  redundancy  of  data. 

Gio  Wiedernold  in  Database  Design  outlines  seven 
measures  of  file  performance.  These  parameters  were 
considered  wnen  designing  tne  physical  data  base.  These 
measures  of  file  performance  include: 

1.  Storage  required  for  a  record 

2.  Time  to  fetch  an  arbitrary  record  from  tne  file 

3.  Time  to  eet  the  next  record  within  the  file 

4.  Time  to  update  by  inserting  a  record  into  tne  file 

5.  Time  to  update  by  changing  a  record  in  the  file 

6.  Time  for  exhaustive  reading  of  the  file 

7.  Time  for  reorganization  of  the  file 

5.  Architectural  Perspective 

The  data  base  system  architecture  is  also  an 
important  consideration.  It  depicts  the  natural,  conceptual 
and  physical  views  of  tne  data  in  tne  data  base.  It  is  tne 
fcey  to  data  independence  and  gives  the  DBMS  much  of  its 
power  and  flexibility. 

At  tne  most  abstract  level,  there  is  tne  external  data 
base.  This  is  the  way  in  which  the  user  views  the  data  base. 
It  consists  of  any  number  of  different  perspectives  of 
individual  users,  which  are  considered  subschemas  of  the 
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data  base.  Typically,  tne  subscnemas  are  more  important  tnan 
an  overall  view  of  tne  external  data  since  tney  define  tne 
information  environment  for  a  single  user  or  specific 
application. 

The  external  data  base  maps  into  tne  conceptual  data 
base  which  is  the  logical  view  of  tne  information  contained 
in  the  data  base.  It  is  tne  schema,  or  combination  of  all 
the  subschema  expressed  in  the  logical  format  of  a  lata 
model.  It  consists  of  tne  records,  relations  and 
relationships  of  the  data  as  well  as  the  primary  and 
secondary  Keys  used  for  processing  tne  data  base. 

The  conceptual  level  maps  into  tne  internal  data  base, 
which,  as  tne  physical  view  of  tne  data,  is  tne  least 
abstract  level  of  the  architecture.  The  physical  data  base 
contains  tne  records,  files,  Indices,  inverted  flies  and 
record  sequences  of  the  data  base.  An  illustration  of  tne 
different  levels  of  tne  data  base  system  architecture  is 
shown  in  figure  9. 


72 


USER 

VIEW 


USER 

VIEW 


USER 

VIEW 


External  View 


6.  Types  of  Systems 

Tne  discussion  so  far  nas  mainly  considered  tne  data 
ftase  management  system  concepts  for  tne  target  information 
system.  Given  tne  nature  of  tne  target  Information  file  and 
the  system  environment,  otner  types  of  systems  near 
consideration.  An  appropriate  alternative  to  a  general 
purpose  DBMS  rri*nt  be  a  sinele  application  system. 

A  single  application  data  base  system  estabilsnes  an 
operation  usin*  tne  available  file  system  facilities  and 
designs  applications  programs  vnicn  interface  to  tne  data 
base.  A  system  for  the  routine  processing  of  data  and  tne 
answering  of  a  prespecified  and  limited  class  of  aueries  is 
sometimes  referred  to  as  an  operations  system.  This  type  of 
system  is  designated  for  a  precisely  defined  and  limited  set 
of  operations. 
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In  a  data  base  management  system  (DBMS),  an  information 
system,  tne  nature  of  tne  queries  will  not  oe  pre-iefinei  by 
the  system  and  lengthy  searches  may  be  necessary  wnen  a 
query  Is  male.  The  capability  to  process  generally  stated 
Queries  Is  characteristic  of  the  multi-purpose  design  of  the 
DBMS  and  often  accounts  for  its  relatively  large  size  and 
cost.  In  an  operations  system,  len<rtny  searches  can 
generally  be  avoided  because  tne  information  is  typically 
stored  in  the  form  it  is  needed.  The  two  types  of  systems 
use  data  bases  wnlcn  are  differently  structured  botn 
logically  and  pnysically. 

B.  LOGICAL  DATA  BASE  DESIGN 
1 .  Data  Splitting 

Given  the  total  information  in  the  tareet 
information  system,  or  more  precisely,  the  set  of  aata  that 
represents  this  information,  it  is  necessary  to  separate  it 
into  subsets  which  can  be  dealt  with  more  or  less 
independentl y. 

The  information  for  tne  system  comes  from  tne  target 
card.  All  of  the  information  pertinent  to  the  data  base  is 
on  tnat  card  or  can  be  implied  from  it.  A  blocs  record  of 
all  of  this  lata  pertinent  to  tne  system  can  be  visualized 
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Figure  9.  Target  Information  Conceptual  Record. 


The  data  can  logically  be  split  into  different  segments, 
for  example,  description  information,  surveillance 
information,  status  information  and  source  information,  but 
a  consideration  of  tne  user  and  tne  conceptual  view  of  tne 
system  is  necessary  first. 

Tnere  is  only  one  user,  tne  target  information  officer 
and  ne  nas  only  one  view  of  tne  data,  tnat  cf  tne  target 
card.  He  may  use  tnat  data  differently  depending  upon  tne 
tactical  situation  or  internal  operating  procedures  but  nis 
logical  view  of  it  nas  not  cnanged.  An  integrated  data  case 
will  nave  many  users  and  many  different  views  of  tne  lata 
(one  scnema  witn  many  subscnema).  The  target  information 
data  base  is  not  an  integrated  data  base  and  it  nas  only  one 
user  and  one  view  of  tne  data,  tnus,  tne  scnema  and  tne 
subscnema  are  tne  same.  Tne  need  for  data  independence 
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(logical  data  la  tnis  case)  is  no  loneer  required  for  tne 
system  because  tae  external  view  is  equal  to  tne  conceptual 
view. 


Splitting  tne  tareet  data  does  not  achieve  any  added 
flexibility,  simplicity,  independence  or  efficiency.  Thus, 
the  target  record  can  consist  of  tr.e  above  24  attributes,  no 
other  relationships  and  be  organized  as  a  flat  file. 

2.  Record  Design 

for  tnis  large  set  of  data  on  target  information,  a 
determination  must  be  made  of  the  format  of  the  record  and 
tne  modes  of  indexing  in  order  to  estaoiisn  tne  index  data 
that  must  be  present.  Two  alternatives  were  considered,  one 
with  a  flat  file  and  a  second  with  multiple  records.  The 
multiple  record  version  merely  added  more  complexity  and 
more  data  to  the  files  with  little  benefit  to  the  system 
other  than  it  ’'looked”  more  use  a  data  base. 

The  flat  file  appeared  to  be  tae  simplest  conceptually 
and  tne  easiest  to  implement.  Tne  data  wttnin  tne  record  was 
ordered  in  a  functional  manner  for  semantic  purposes  and  tae 
primary  and  secondary  iteys  were  determined. 

Tnere  is  only  one  way  to  uniquely  identify  a  target  and 
that  is  by  tne  target  number.  This  is  primarily  dictated  by 
doctrinal  procedures  since  tne  target  alpna/numeric 
combination  determines  the  ori*inatlne  unit  as  well  as  a 
specific  target.  Target  grid  coordinates  may  be  considered 
as  an  additional  unique  tcey,  nowever,  a  single  map  location 
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can  be  targeted  for  multiple  purposes.  Therefore.  toe  target 
number  was  selected  as  tne  primary  icey  for  the  record. 

Tnere  are  a  number  of  secondary  Keys  for  eacn  target  out 
only  a  few  of  these  nave  a  real  meaning  to  tne  TIO.  Those 
Keys  vnicn  will  be  needed  to  access  certain  types  of  target 
Information  nave  been  selected  as  secondary  Keys.  It  is  for 
these  Keys  tnat  tne  queries  to  tne  data  base  win  ie 
designed.  Figure  10  illustrates  the  primary  and  secondary 
Keys  of  tne  target  record. 


Figure  10.  Primary  and  Secondary  Keys. 

3.  Volume  and  Activity  Anal  s- 

— — — — — I  '  ">  ■  ■—  t 

Estimates  must  be  r.i^-e  of  individual  record  sizes 
and  tnen  of  tne  expected  file  sizes  as  well  as  determining 
the  frequency  of  reference  of  information  in  tne  data  base. 
In  determining  record  size,  a  number  of  considerations  came 
into  play.  Data  items  which  could  be  derived  or  implied  from 
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other  data  items  were  deleted.  For  example,  if  a  target  had 
a  BDA  in  tne  record,  it  nad  been  attached  by  supporting 
arms.  If  tnere  were  no  JJDA,  the  target  had  not  been 
attached. 

Additional  attributes  were  identified  wnose  requirements 
were  implied  by  otner  lata  items.  For  example,  target  type 
was  made  a  record  attribute  (and  a  secondary  Key)  since  the 
target  description,  being  text,  would  nave  to  be 
semantically  analyzed  in  order  to  reveal  all  targets  of 
enemy  "artillery”. 

Attempts  were  made  to  reduce  tne  size  of  stored  data  cy 
encoding  tne  domains  of  attributes.  The  domain  for  target 
priority  is  [I*  II,  III,  IVJ  .  To  place  priority  III  in  tne 
target  record  file  would  taice  three  characters;  reduced  to  a 
numerical  representation,  it  tares  only  one  number  (3). 
Target  damage  is  described  by  a  maximum  of  eight  different 
words,  the  largest  of  which  is  11  characters.  This  has  been 
reduced  to  a  single  number  from  one  to  eight. 

A  data  dictionary  was  developed  whicn  listed  eacn 
attribute,  its  domain,  data  item  size  ana  data  type  (see 
appendix  A).  From  this  document,  the  size  of  tne  record  was 
determined  to  be  approximately  240  bytes.  Since  adequate 
secondary  storage  appeared  to  be  available,  a  fixed  length 
record  was  selected.  In  addition,  since  more  tnan  one  3DA 
was  expected  for  a  given  target,  tne  record  size  was 
increased  to  three  BDA  per  target  bringing  the  record  size 
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to  approximately  370  bytes.  With  a  maximum  of  300  tareets  in 
tne  system,  tne  file  would  occupy  appproximately  110K  bytes 
of  secondary  storage. 

An  estimate  was  male  of  tne  number  and  type  of 
references  to  tne  data  based  on  tcnown  ana  anticipated 
tactical  requirements.  A«ln,  tne  design  restrictions  on 
what  tne  user  could  ass  of  tne  data  case  played  an  important 
consideration.  The  majority  of  the  information  for  retrieval 
was  either  an  individual  target  card  or  a  list  of  specific 
tareets.  Return  of  the  target  card  to  tne  user  was  a  simple 
matter  for  file  design,  merely  retrieve  tne  record  from  tne 
data  base  and  display  all  of  tne  information.  Tne  retrieval 
of  specific  information  is  more  complicated. 

The  specific  information  about  targets  is  best  displayed 
as  a  target  list  since  tnat  is  tne  most  useful  format  for 
the  user.  Figure  11  is  an  example  of  the  format  required 
from  tne  data  base. 
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LIST  OF  TARGETS 


TGT  NO 

CL 

PR  I 

LOCATION 

ALT 

SA 

DESCRIPTION 

AA0021* 

C 

II 

34566543 

90 

AIR 

2  T-62  TANKS 

AA0020 

c 

IV 

23455565 

40 

NGF 

5  INCH  COASTAL  GUN 

AA0056* 

E 

IV 

67565466 

50 

NONE 

4  SCHOOL  BUILDINGS 

AA0013* 

A 

III 

55677412 

15 

NGF 

BUNKERED  TRENCHLINE 

AZ1022 

D 

II 

76835454 

110 

ART! 

BN  ASSEMBLY  AREA 

AZ1005* 

C 

I 

34345656 

20 

ARTY 

PLT  ZSU  23-4 

AA0012 

B 

III 

56445456 

10 

NGF 

CONCRETE  BUNKER 

NOTE:  *  indicates  target  list 


Figure  11.  Example  of  a  Target  List. 


4.  Design  Conclusions 

Because  tae  data  base  is  a  single  application  data 
base  and  is  an  operations  system  ratner  taan  an  Information 
system,  tne  use  of  a  specific  data  model  was  rejected.  Tae 
flat  file  format  lends  itself  to  tae  relational  •nodel  and 
tne  resultant  system  approximates  tne  relational 
metaodology.  The  system  does  qualify  as  a  data  base. 
However,  it  is  a  very  restricted  one  due  to  its  specific 
purpose. 

Access  to  the  data  base,  eiven  tae  limited  '-hoice 
imposed  upon  tne  user  by  tne  system  design,  was  by  extending 
the  host  language  ratner  than  the  use  of  a  query  ianguaee  or 
imbedded  data  language.  Tne  record  design  incorporates  tne 
target  information  as  one  record  with  one  primary  and  seven 
secondary  Keys  for  a  total  of  22  attributes.  Tnis  monoiitnic 
record  is  depicted  in  figure  12. 
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Target  Description 


C.  PHYSICAL  DATA  EASE  DESIGN 
1 .  System  Output 

The  system  output  must  be  considered  tefore 
discussine  the  physical  data  base  desien.  These  end-products 
require  a  certain  content,  format  and  response  time. 
Retrieval  of  information  for  the  TIO  must  be  rapid  and  the 
physical  design  of  the  data  must  facilitate  speed,  even  at 
the  cost  of  storage  efficiency. 
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These  items  of  system  output  nave  previously  been 
identified  and  are  depicted  schematically  in  figure  13: 


Figure  13.  System  Output. 


2.  Index  File  Design 

The  choice  of  file  organization  is  dependent  upon 
the  record  structure*  the  physical  distribution  of  tr.e 
records  in  tne  storage  device  and  the  indexing  method 
employed  to  reference  the  recorl.  To  some  degree,  the  amount 
of  storage  space  available  will  influence  tne  file  design  as 
well.  The  critical  issue  is,  however,  the  efficiency  of  its 
performance. 

The  record  is  accessed  by  its  primary  Key.  Tne  target 
number,  unfortunately,  is  not  always  assigned  in  sequence. 
Thus,  there  is  no  logical  order  inherent  in  the  target 
number  although  tney  could  be  ordered  in  numerical  sequence 
for  the  satte  of  order.  But  there  is  no  consistent  order  to 
warrant  tne  use  of  sequential,  indexed  sequential,  nasned  or 
binary  tree  storage  schemes.  The  use  of  the  dense  index 
allows  us  to  access  tne  required  target  efficiently  (witn 
only  300  targets)  as  well  as  insert  new  targets  easily  at 


tne  end  of  tne  file,  wnile  deletion  of  targets  would  leave 


noles  in  tne  storage  file,  an  unused  target  space  record 
could  be  maintained  wnicn  would  Keep  tracK  of  tne  noles  and 
assign  newly  inserted  records  in  tne  available  space. 

Tne  dense  index  would  nave  to  be  made  on  botn  the  target 
number  and  tne  grid  coordinates,  since  it  is  a  doctrinal 
requirement  to  be  able  to  sort  on  botn.  Tne  UCSD  Pascal 
implementation  mates  tnis  a  mucn  easier  operation  witn  its 
string  intrinsics  and  random  access  capability  of  relative 
records.  Tnis  also  allows  tne  index  to  be  stored  as  a 
subscripted  array  and  enables  tne  system  software  features 
to  do  most  of  tne  manipulation.  The  index  design  is 
illustrated  in  figure  14.  It  is  essentially  two  arrays  earn 
consisting  of  tne  target  number  or  tne  grid  location  for 
eacn  of  tne  allowable  300  targets. 
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Target  File  Index  Design. 


Ttie  ease  of  tae  UCSD  Pascal  random  access  capability  is 
illustrated  in  figure  16.  Tne  SEEK  command  on  tne  file  name 
and  tne  record  number  provide  for  a  base  address  and  an 
offset  to  tne  required  target  number.  Tms  allows  for  qulci 
and  easy  access  to  any  target  requested  by  tne  user. 


Figure  15.  UCSD  Pascal  Random  Access  Capability. 
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3.  Pnyslcal  Design  Alternatives 

Tne  file  design  will  permit  easy  and  efficient 
access  to  tne  target  record.  Tne  display  of  tne  target  card 
is  essentially  solved  by  tnis  design.  Wnat  remains  is  tne 
accessing  of  tne  important  attributes  for  tne  target 
listings  by  specific  parameter,  i.e.,  tne  queries  from  tne 
TIO. 

The  most  straieht-f orward  approach  is  to  access  all  of 
tne  required  data  from  tne  target  file.  An  efficient  metnod 
of  doins  this  would  be  to  use  multi-linked  lists  tnrousn  tne 
appropriate  data  items.  Header  records  would  provide  a 
pointer  into  the  file  and  links  would  provide  access  to  each 
item  of  specific  data.  Tnere  are  overnead  considerations  in 
tnis  approach,  particularly  in  rearranging  tne  links  wnen 
adding  or  deleting  a  target. 

A  major  disadvantage  to  tnis  approach  is  tne  estimated 
time  it  would  take  to  process  a  query.  If  all  priority  I 
targets  are  to  be  retrieved,  tne  program  module  must  find 
the  header  index  and  follow  the  pointer  tnrou«h  the  tareet 
file  until  it  found  eacn  of  tne  priority  I  targets. 

The  disk  accessing  to  secondary  storage  is  a  bottleneck 
in  a  microcomputer  and  snould  be  minimized  whenever 
possible.  The  access  time  to  find  all  priority  I,  class  C, 
previously  attacked,  tank  targets  could  oe  quite  lengtny. 
Arranging  tne  file  into  blocks  of  five  to  ten  target  records 
per  block  would  decrease  the  amount  of  disk  accesses. 
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A  second  approach  would  be  to  use  an  inverted  file 
structure  (often  used  in  data  oase  systems  to  improve  cirect 
access  to  certain  data)  for  each  of  the  secondary  Keys  with 
a  pointer  (actual  or  symbolic)  to  eacn  of  tne  specific 
records.  An  access  to  the  entire  inverted  file  index  would 
identify  by  name  or  by  location,  eacn  of  tne  applicable 
records.  Once  determined,  tne  records  could  be  retrieved. 

To  process  a  target  list  with  multiple  parameters,  only 
the  target  numbers  from  the  indices  need  to  be  read  into 
memory  and  tne  appropriate  intersection  made  of  tne  common 
record  attributes.  This  would  entail  one  seek  per  index  and 
tnen  one  sees  for  eacn  appropriate  record.  Additional 
efficiency  is  obtained  if  all  tne  index  files  are  read  into 
main  memory  wnen  tne  user  is  going  to  maKe  accesses  to  tne 
data  base.  This  will  reduce  the  number  of  disK  seeKs 
required  to  access  records  and  is  particularly  effective  for 
multi-parameter  queries. 

There  is  a  bit  more  efficiency  in  the  second  method, 
particularly  in  accessing  data  with  multiple  parameters  but 
the  cost  is  in  use  of  more  secondary  storage  for  the 
inverted  files.  With  tne  amount  of  secondary  storage 
available  (see  the  estimate  in  fi*ue  7),  tne  trade-off 
between  storage  space  and  processing  speed  is  considered 
acceptable. 

A  third  alternative  is  even  more  expensive  in  terms  of 
secondary  storage  since  it  calls  for  redundancy  of  target 
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subset 

of 

tne  main  target  file 

can 

be 

formed  to 

provide 

tne 

data 

in  a  more  accessible 

form. 

Tne 

file  would 

be  a  separate  record  extracted  from  tne  mala  target  file  and 
consist  of  only  tnose  attributes  or  items  wnicn  will  be 
needed  for  tne  target  auery  and  tne  resulting  output 
listing.  Tnis  would  eliminate  tne  need  to  access  tne  main 
target  file  for  queries  since  all  tne  system  queries  would 
be  confined  to  tne  data  base  query  file.  Once  tne  target 
number  was  identified  by  tne  query  mecnanism,  tne 
appropriate  target  listing  information  would  be  '  obtained 
from  tne  file  and  displayed  on  tne  CRT  screen. 

Tnis  data  base  query  file  would  nave  records  of  45  bytes 
in  lengtn  witn  a  maximum  file  size  (for  300  targets^  of 
about  145  bytes.  Tne  logical  record  is  illustrated  in  figure 
16.  To  access  tne  lata  in  tnis  file,  tne  inverted  inaei 
files  could  be  usei . 


Figure  16.  Data  Base  Query  File  Logical  Design. 

Tne  data  base  query  file  would  be  loaded  into  main 
memory  eacn  time  tne  Query  module  is  activated.  Tnere  is  no 
requirement  tcv>write  tne  file  to  secondary  storage  wnen  tne 
Query  module  is  deactivated  since  tnere  will  be  no  cnanges 
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male  to  the  file.  In  tnat  tne  Query  module  and  tne  data  tase 
query  file  would  be  s imul taneousiy  located  in  main  memory, 
queries  could  ce  quietly  and  efficiently  processed. 

Tnis  eliminates  tne  need  to  access  tne  dlsic  to  perform 
queries,  tnerefore  greatly  reducin'?  tne  processing  time.  Tne 
cost,  however,  is  in  an  additional  file  in  secondary 
storage,  an  array  to  noil  tne  data  base  query  file  in  main 
memory,  redundancy  of  data  and  tailoring  of  tne  data  base 
auery  file  and  tne  Query  module  to  fit  into  main  memory 
simultaneously.  There  is  also  tne  added  complexity  to  tne 
program  when  additions,  deletions  and  changes  are  made  to 
tne  main  file  in  tnat  tnese  changes  must  also  be  reflected 
in  tne  data  base  query  file. 

Consideration  was  given  to  doine  all  updates  to  the  data 
base  query  file  wniie  it  was  located  in  main  memory  since 
the  array  which  nolds  tne  records  is  a  static  data 
structure.  While  it  would  improve  system  efficiency  and 
preclude  loadine  tne  data  base  query  file  each  time  tne 
module  was  called,  tne  cnances  of  loss  of  data  through  a 
power  suree  or  a  system  failure  are  sufficiently  *reat  to 
eliminate  tnis  approach.  Tne  differences  between  tne  two 
data  files  after  a  Ion*  period  of  uninterrupted  operation 
would  render  tne  query  capabilities  invalid’  because  of 
inconsistent  data.  The  expected  configuration  of  tne 
allocation  of  main  memory  during  data  base  query  operations 
is  snown  in  figure  17. 
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Figure  17.  Main  Memory  Map  For  Data  Ease  Cuerles 


While  each  of  tne  above  alternatives  supports  the 
loeical  desien  of  tne  data  base,  the  third  alternative  is 
tne  fastest  and  was  selected  because  of  tne  user's  need  for 
timely  access  to  the  data  base  information.  Tne  expensive 
trade-off  in  added  complexity  and  redundancy  is  made  in 
favor  of  tne  user. 

4.  Inverted  File  Design  Considerations 

An  inversion  on  tne  secondary  keys  would  allow  tne 
system  to  conduct  multiple-key  Drocessine  of  queries.  Earn 
of  tne  secondary  keys  would  nave  a  separate  inverter  file 
for  each  of  the  values  of  tneir  domain.  Tne  index  would 
contain  tne  actual  pointer  to  tne  appropriate  record  m  tne 
data  base  query  file.  An  example  of  an  inverted  file  for  the 
target  priority  attribute  is  snown  in  figure  18. 
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Target  Priority  Index 


Figure  19.  Example  of  an  Inverted  File  Logical  Structure. 

The  implementation  of  tne  Inverted  flies  couia  employ  a 
linked  list  of  tne  target  location  pointers  ov  specific 
domain  of  tbe  attribute.  However,  tills  file  must  be  updated 
eac.n  time  tne  user  adds  or  deletes  a  target  from  tne  system 
as  well  as  maKes  a  specific  change  wnicn  will  affect  tile 
index.  For  example,  a  priority  I  target  could  be  cnangea  to 
a  priority  IF  target  after  successful  attaoK  by  supporting 
arms.  Tnis  would  necessitate  a  cnange  in  tne  mam  target 
file,  tne  data  base  query  file  and  tne  inverted  index  for 
target  priority  (botn  for  priority  I  and  I'M  as  well  as  an 
input  for  tne  transaction  log  of  tne  TARBUL. 

Tnis  disadvantage  combined  witn  tne  complexity  of 
implementing  linked  lists,  maintaining  multiple  inverted 
index  files  and  tfte  overhead  involved  detracts  significantly 
from  tne  elegance  of  using  inverted  files.  A  simple, 
practical  and  straight-forward  solution  is  required. 


6.  Flat  File  Array  Processing 

The  data  base  query  file  Is  implemented  as  a  single 
dimension  array  of  records  so  tnat  it  can  be  ioadea  into 
main  memory.  Ttie  lTCSD  Fascal  system  performs  effective  array 
processing  and  tnis  feature  can  be  used  to  perform  tne  data 
base  query  functions.  The  method  selected  for  the  target 

T' 

information  system  is  array  processing  of  tne  flat  fixe. 

The  Ouery  module  prompts  the  user  to  select  the  special 
criteria  for  tne  target  listing.  It  does  tnis  by  presenting 
the  user  a  series  of  menus  from  which  the  secondary  Keys  and 
tneir  respective  domain  attributes  can  be  selected.  Once  tne 
attribute  is  selected,  the  module  processes  the  array  to 
determine  if  tne  targets  in  the  array  possess  tnis 
attribute.  Sacn  target  with  tne  attribute  is  flagged  and  tne 
system  returns  to  tne  menus  for  furtner  Key  selection.  A 
domain  can  be  selected  only  once  per  list.  Tnus,  tne  system 
permits  only  tne  logical  "ANDING"  of  one  attribute  of  tne 
domains  of  tne  secondary  Keys. 

Upon  selection  of  another  attribute,  the  system  will 
process  only  tne  targets  which  were  flagged  oy  the  previous 
array  processing.  This  will  significantly  reduce  the  search 
time  and  result  in  increasingly  greater  refinement  of  tne 
list  for  each  subsequent  part  of  the  query.  Since  there  are 
only  six  secondary  Keys,  tne  maximum  query  size  is  six  items 
although  tne  user  could  stop  snort  of  that  number  at  any 
time  in  tne  processing.  Wnen  tne  user  stops  tne  query  and 
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requests  tne  listing,  tnose  targets  which  are  flagged  are 
accessed  and  written  to  tne  console  screen.  Wnen  tne  next 
query  is  initiated,  ail  tne  flags  are  reset. 

Two  additional  design  features  nave  oeen  incorporated  to 
speed  tne  array  processing.  Tne  first  feature  is  tne  storage 
cnaracteristics  of  tne  secondary  iceys  in  tne  record.  Eacn  is 
stored  as  a  single  cnaracter  requiring  no  type  conversion 
tnus,  enabling  quiet  ana  easy  comparisons.  Tine  second 
feature  is  in  tne  design  of  tne  query  menus. 

The  menus  nave  been  arranged  so  tnat  tne  most 
discriminating  Indices  are  presented  to  tne  user  first. 
Target  type  aas  a  domain  of  nine  values  and  is  presented 
first  to  tne  user.  Tnus,  tne  first  pass  at  tne  target  list 
will  probably  result  in  tne  smallest  list  of  flagged 
targets.  This  reduces  the  amount  of  array  processing  for  the 
remaining  portions  of  tne  querv.  For  example,  if  tne  system 
nas  1216  targets  and  82  of  tnese  are  "active”  status  and  14 
are  of  type  "tanit’’,  tnen  the  first  pass  in  eitr.er  case  will 
be  for  all  1 22  targets.  If  status  was  the  first  part  of  the 
query  tnen  tne  next  search  would  be  tnrougn  82  ’"active" 
targets  until  the  "tame”  targets  were  found.  However,  if 
type  was  tne  first  part  of  tne  query,  only  14  records  of 
type  "tame"  would  nave  to  be  searched  to  find  the  "active" 
targets.  Tne  first  searen  processed  192  targets,  tne  second, 
using  tne  least-list  principle,  processed  only  114  targets. 


Tne  pnysical  design  of  tne  lata  base  query  file  is  sr.o*n 
in  figure  19. 

OUERY  ITEMS  TEXT 


F....Flag  P. .. .Priority 

T....Type  A ...  .Accuracy 

C..  ..Class  S... .Status 

SA ..  .Support! ng  Arm 

Figure  19.  Data  Ease  Cuery  File  Pnysical  Design. 

5.  Data  Ease  Partitioning 

In  addition  to  tne  main  target  file  and  tee  lata 
base  Query  file  addressed  above,  tne  functions  of  tr.e  system 
require  additional  file  considerations.  In  particular,  tnere 
is  tfte  requirement  to  produce  a  TAREUL  *nen  requested  by  tne 
TI3.  Tne  system  must  retain  in  a  separate  file,  an  tne 
information  tnat  is  appropriate  for  tne  TARBUL.  Typically, 
tnis  information  consists  of  targets  added  to  or  deleted 
from  tne  target  list,  cnanees  to  targets  on  tne  target  list 
and  significant  BDA  on  attached  targets.  Tne  Target  module 
of  tne  applications  program  extracts  and  formats  tne 
appropriate  information  for  tne  TARBUL  file  in  conjunction 
witn  normal  processing. 


A  security  feature  of  tne  system  is  a  user  defined 
password  wnicn  allows  entry  into  tne  program  only  wnen  tne 
proper  password  nas  been  received,  in  order  to  provide  for 
tne  retention  of  passwords  between  uses  of  tne  system,  a 
small  file  was  constructed  wnicn  contained  tne  user 
password.  A  procedure  of  tne  system  allows  tnis  password  to 
be  written  to  tfte  diskette  and  retrieved  wnen  tne  system  is 
activated. 

Tnere  is  a  requirement  to  provide  tne  user  witn  a  file 
status  report  on  a  periodic  basis.  It  is  essentially  a 
statistical  breakdown  giving  tne  number  of  active  targets, 
inactive  targets  and  targets  on  tne  target  list  as  wen  as  a 
count  of  tne  targets  in  eacn  attribute  by  domain.  A  separate 
file  could  be  kept  for  tnis  information,  but  to  decrease 
complexity  ana  storage  requirements  for  tne  system,  a 
routine  from  tne  Utility  module  is  used  to  accumulate 
statistics  from  tne  data  base  query  file  and  display  tne 
information  to  tne  CRT  screen  wnen  reauested  Dy  tne  user. 
Once  again,  naving  tne  data  base  query  file  in  main  memory 
will  reduce  tne  '•omputa  tio  n  time  needed  for  tnis  process. 

Tne  data  base  is,  tr.us,  partitioned  into  two  data  Ease 
files  (one  a  suDset  of  tne  otner)  and  two  utility  files,  tne 
TARBUL  file  and  tne  password  file.  Tney  must  snare  secondary 
storage  space  witn  routines  of  tne  operating  system  and  tne 
applications  program  object  code.  Tne  partitioning  of  tne 
data  base  is  depicted  in  figure  RE. 
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Figure  'Z'£ .  Data  Base  Partitioning. 


D.  OTHER  CONSIDERATIONS 

In  considering  inverted  files,  it  was  determined  tfta t 
some  record  attributes  did  not  yield  a  sufficiently 
discriminati ne  index.  For  example,  the  data  item  "status" 
yielded  a  poor  index  since  only  two  values  are  possicie, 
active  and  inactive.  In  an  effort  to  estaniisr  more 
discriminatory  indices  and  at  tne  same  time  reduce  tne 
pnysical  size  of  tne  data  items  in  a  record,  index  items 
were  combined  and  compressed  in  a  coded  form.  Target  status 
was  enlarged  to  encompass  tne  target  list  index  and  tne 
target  attacKed  index.  Tne  combining  of  tr.ese  tnree  indices, 
eacn  wi tn  aomai ns  of  value  two ,  yields  one  inc ex  wit n  a 
valid  domain  of  six  values.  Tne  newly  formed  index  is  as 
follows : 
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The  lata  lictionary,  which  was  developed  in  response  to 
the  volume  analysis  of  tne  data  case  record,  addresses  eacn 
attribute  separately  by  name,  data  type,  physical  size, 
logical  size  and  lists  the  domain  where  appropriate. 
Specifics  about  the  tarset  record  and  the  query  record  are 
listed  as  well  as  a  determination  of  the  physical  record 
size.  All  tne  data  in  tne  record  is  in  ASCII  character 
format*  even  items  sucn  as  tne  grid  location  and  altitude, 
which  are  actually  integer  values,  are  stored  as  characters. 
Conversion,  vnen  necessary,  is  performed  by  tne  applications 
program . 

E.  SUMMARf 

The  primary  consideration  in  tne  design  of  tne  data  base 
was  ease  of  use  and  speed  for  the  user  in  tne  microcomputer 
environment.  This  consideration  overrides  tne  inefficiencies 
of  a  dual  data  base  record.  Moreover,  the  complexity  of  the 
processing  requirements  is  invisible  to  tne  user.  He  is 
concerned  only  with  fast  retrieval  of  certain  types  of 
information.  As  tne  casual  user,  ne  is  not  concerned  with 
nieh  level  query  ian«rua*es  and  their  use.  Rather,  he 
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requires  a  macnine  tnat  will  serve  nls  needs  and  not  tne 
otner  way  around. 

£.  F.  Codd,  in  nis  1974  article  Seven  Steps  to 
Rendezvous  with  tns  Casual  User  stated  tnat  "it  is  projected 
tnat  by  tne  turn  of  tne  century,  tne  majority  of  data  base 
management  systems  will  be  oriented  toward  tne  casual  user’ . 
A  system  wnicn  will  oe  able  to  perform  its  function  quicsiy, 
easily  and  accurately  during  tne  intensity  of  combat 
operations  will  be  tne  one  tnat  is  specifically  designed  to 
conform  to  tne  user's  environment.  Tnis  system  was  designed 
witn  tnis  principle  in  mind. 
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INTERACT  1 7?  UTEEFACE  DESIGN 


A.  GENERAL 

One  of  tne  major  lesion  features  of  tne  target 
information  system  is  tnat  it  proviie  a  friendly  yet 
sopnis ti ca ted  user  interface.  It  snouid  oe  sufficiently 
scpnisticatea  to  perform  an  of  tne  reuuireo.  functions 
simply  and  efficiently  witn  only  a  minimum  of  interaction 
from  tne  user.  Tne  environment  must  be  a  friendly  one, 
allowing  tne  user  to  recover  gracefully  and  witn  mininum 
effort  from  error,  guiding  tne  correct  input  and  providing 
tne  user  witn  assistance  or  information  wnen  needed. 

Tne  user  is  a  Marine,  trained  in  tne  conduct  of 
supporting  arms  operations  in  a  comoat  environment.  He  is  a 
parametric  user,  a  casual  operator  or  a  computing  macnine, 
witn  no  computer  training  ana  a  limited  capacmty  of 
operating  a  computer.  Tne  system  must  De  sufficiently  simple 
for  tnis  user  to  learn  to  operate  it  er'fectiveiv  in  a 
■minimum  of  time  and  witn  a  minimum  of  effort.  It  must 
inspire  nis  confidence,  simplify  nis  tasic,  increase  ms 
effectiveness,  reduce  or  eliminate  any  computer  "anxiety" 
and,  most  importantly,  enable  nim  to  accurately  ana  auLCKiy 
carry  out  nis  mission. 

This  chapter  outlines  the  design  criteria  ana  tecnniaues 
used  in  determining  tne  quality  of  tne  man-macnine 


interface.  Tnese  criteria  were  employed  in  tne  lesion  oi  me 
applications  program  ar.d  constitute  its  tasic  rranewor*.  Tne 
system  effectiveness  can  only  ce  measure!  Dy  now  wen  tr.e 
interface  oetween  tne  nan  ana  tne  macnine  nas  succeeaea. 
Janes  Martin,  in  nis  Design  or  Man-Computer  Dialogue 
descriced  tne  psycnoiogicai  impact  of  tne  interactive 
interface  cn  tne  user  as  follows: 

"it  nas  become  increasingly  realized  mat  many 
information  processing  operations  are  nest  carried  out 
not  Dy  macnine  alone,  nor  oy  man  alone,  out  Dy  a 
judicious  comoination  of  man  and  macnine...  A  ney  to 
success  in  many  real  time  operations  lies  in  in° 
recognition  of  machine  limitation  and  tne  ouiidin*  into 
tne  system  of  appropriate  auman  capaDiiities.” 

B.  DESIC-N  PRINCIPLES 

Tnere  are  four  oasic  principles  used  m  tne  aesmn  of 
tne  user  interface.  First,  it  must  be  self -explanatory .  Tne 
user  must  be  able  to  use  tne  system  witnout  reference  to  an 
external  source .  Tnis  implies  tnat  tne  system  guice  and 
direct  tne  user  in  tne  execution  or  nis  tasars  regardless  or 
nis  level  of  expertise.  Tnis  requires  simplicity,  ease  of 
use,  and  elimination  of  system  failure.  Second,  tne  syster 
must  be  self-neiping .  iVaenever  tne  user  wants  or  requires 
help  or  assistance,  tne  system  must  responi.  It  snouii 
identify  tne  improper  input,  guiae  tne  user  tc  tne  crcper 
input  required  and  provide  an  example  of  tne  correct  input 
wnen  appropriate.  Accordingly,  error  messages  must  re 
explanatory  anl  tne  system  must  respond  to  every  input. 


continue!  exposure  to  tne  same  type  of  information, 
snort-term  memory  retention  can  te  improve!  out  essentially, 
we  are  aDie  to  retain  only  a  limited  amount  of  information 
at  one  time.  Ceorge  Miller's  classic  paper  in  iy&<3.  Tne 
Magical  Number  Seven — Plus  or  Minus  Two,  descrioel 
experiments  wnicn  suggested  tnat  tne  snort-term  memory  was 
limited  to  a  perception  of  aoout  seven  units.  Jor  terminal 
interaction,  tnis  implies  tnat  tne  processing  capacity  of  an 
individual  is  limited  to  only  a  few  items  ana  tnat  it  snouid 
be  tatcen  into  consideration  wnen  designing  menu  formats. 
Tney  snouid  be  simple,  semantically  meaningful,  arranged  in 
a  logical  progression  (to  tne  user... not  tne  programmer)  and 
brief. 

i .  Closure 

Tnere  is  great  psycnoiogicai  relief  to  snort-term 
memory  wnen  information  no  longer  needs  to  oe  retained.  Tnis 
produces  a  powerful  desire  to  complete  a  tasi  witnin  tr.e 
snort-term  memory  span,  reduce  tne  memory  load  ana  gain  tne 
psycnoiogicai  relief.  Closure  is  tne  completion  of  a  tasi 
leading  to  tnis  relief.  Tne  user  expects  to  experience 
closure  after  completing  an  activity.  Any ‘delay  in  acnievmg 
closure  or  tne  interruption  of  tnis  process  is  frustrating. 

Tne  pressure  for  closure  implies  tnat  tne  user 
(particularly,  tne  novice  or  parametric  user)  will  prefer 
multiple  small  operations  ratner  tnan  one  large,  complex 
one.  In  system  design,  tnis  suggests  tnat  interactions  ce 
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defined  in  sections  or  logical  segments  so  mat  completion 
can  re  obtained  ana  information  released.  All  actions  cf  tne 
user  snouia  ce  responded  to  in  a  positive  manner  07  tne 
system. 

3.  Uspr  Anxiety 

Tne  user  attitude  toward  tne  computer  can  impact 
upon  nis  iearnin?  ana  performance  witn  tne  system.  Computer 
’’anxiety",  generated  oy  fear  of  failure,  may  reduce  tne 
user's  sr.ort-tren  memory  capacity  ana  infticit  nis 
performance.  Tne  system  snouia  put  tne  user  at  ease  out 
witnout  oein?  patronizing,  obvious  or  cute.  Tne  user  will 
respond  better  if  tne  instructions  are  dear,  unambiguous , 
expressed  in  familiar  terms  and  easy  to  follow.  Constructive 
advisory  messages  and  positive  reinforcement  are  preferea  to 
tnreatenine,  condemning  or  meaningless  error  messages, 
"please  reenter  your  cnoice"  is  more  user  friendly,  less 
intimidating  and  more  effective  tnar.  ".Bad  entry-error  Hi" . 
Tne  target  information  system  nas  been  designed  to  provide  a 
comfortable,  nelpful  ana  friendly  environment. 

4.  Control 

A  driving  force  in  numan  nature  is  tne  desire  tc 
control.  In  using  computers,  tne  novice  is  perfectly  willing 
to  follow  tne  computer's  instructions  and  accept  tne 
computer  as  tne  controlling  a?ent  in  tne  interaction.  As  nis 
level  of  experience  increases,  tne  user  may  resent  tne 
computer's  dominance  and  may  loot  at  tne  computer  only  as  a 


tool.  Taus,  me  system  snouid  ce  designed  to  er.aance  me 
user  control  or  at  least  tae  appearance  cf  user  control. 
Properly  formatted  means,  aavlsory  messages  ana  error 
diagnostics  can  give  tae  user  tae  impression  mat  ae  is  ir. 
complete  control  of  tae  situation.  Tae  menu  allows  air  to 
maie  decisions  on  input  parameters  as  wen  as  selecting 
different  functions. 

D.  .HA'S  PONS  £  TIMS 

A  simple  limit  or.  response  time,  tae  time  it  taxes  for 
tne  system  to  respond  to  a  command,  is  desiratie  for 
effective  man-macnine  interface.  An  acceptaoie  response  time 
is  a  function  oi  tne  type  of  command  ana  tne  user's 
expectation  of  wnat  a  reasonaDie  response  time  is.  for  some 
operations,  ae  is  content  to  let  tne  macnine  cruncn  a*ay  cut 
for  otaers,  ae  expects  an  immediate  response.  Tne  timeliness 
of  response  to  target  information  queries  was  tne  primary 
factor  for  tne  design  of  tne  dual  data  case. 

In  normal  conversation,  tne  user's  expectancy  of  a 
response  is  wltnin  aoout  two  seconds.  A  lac*  of  response 
•witnin  four  seconds  would  Oe  an  unnatural  Dreajf  in  tne 
conversation.  In  studies  of  man-macnine  interface,  a 
response  witnin  two  seconds  nas  Deer,  shown  to  constitute  an 
important  and  reasonaDie  Doundary  m  tae  effectiveness  of 
feedDactc.  Errors  must  oe  responaea  to  witnin  two  tc  fcur 
seconds  so  mat  tne  closure  perioa  is  forces,  at  tne 


appropriate  time,  wnlie  system  mi ta li za tlon  may  ce 
acceptable  to  toe  user  wimin  seconds,  ne  exper-ts  to 
access  tne  next  menu  or  to  receive  input  neap  axncst 
instantly.  men  tne  delay  is  expectea  to  exceea  tr.e  two 
secona  parameter,  tne  system  snoula  acxr.owieage  tne  connana 
anl  inai cate  tnat  processing  is  underway  (ana  periodically 
reinforce  mis  until  tne  process  is  complete).  Tais  ensures 
tnat  tne  user  snows  nis  cc.mmana  nas  been  accepted  ana  tne 
nacnine  is  processing  tne  request  ratner  tnan  observing  a 
clans  screen  and  wondering  wnat  to  ao  next. 

i!.  INPUT  MODES 

1 .  Mode  Selection 

Among  tne  different  types  or  interactive  dialogues 
considered,  computer  initiated,  form  fining  ana  menu 
selection  were  determined  to  oe  tne  most  appropriate  for  tne 
parametric  user  ana  tne  specific  application  of  target 
information.  A  combination  of  tnese  tnree  metnoas  provides 
flexibility,  ease  of  use,  simplicity  ana  covers  a  complete 
range  of  tne  system  functions. 

Tne  computer  initiatea  dialogue,  wnere  tne  user  responds 
to  tne  computer,  nas  tne  advantage  of  requiring  very  uttie 
training  for  tne  user  to  opera te  tne  sys tern.  However ,  tne 
dialogue  can  oe  ratner  lengtny,  tne  system  can  ce  ratner 
slow  to  respond  and  mere  is  a  loss  of  flexibility  m  tne 
sequence  of  tne  iialoeue.  Tne  form  filling  tecnnique,  wnere 


tne  user  fills  out  form  on  a  visual  aispiay  aevice,  is 
strsigr.t  forward  for  tne  operator  in  tr.at  an  r.e  needs  to  ao 
is  provide  tne  appropriate  information.  Error  diagnosis  must 
De  immediate  to  oe  effective  ana  cursor  manipulation  must  ce 
considered . 

Menu  selection,  wnere  tne  user  selects  an  appropriate 
response  to  a  number  of  cr.oices,  reauires  little  or  no  user 
training  ana  nas  tne  advantage  taat  tne  user  may  ce  informed 
aoout  tne  full  range  of  tne  system  features.  A  simple  exit 
from  tne  menu  sequence  and  tne  opportum ty  to  return  to 
previous  menus  enables  tne  user  to  acnieve  flexibility  to 
navigate  tnrougn  tne  system.  Tne  umitea  number  of  cnoices 
on  any  particular  frame  ana  tne  information  acout  tne 
sequence  of  frames  wcicn  leads  to  tne  current  one  provide  a 
narrow  context  witnin  wnicn  it  is  easy  to  design  effective 
user  aids  and  error  messages. 

Menu  selection  is  a  form  of  computer  initiated  dialogue 
since  it  is  asrine  cne  user  a  question  and  providing  a 
limited  set  of  valid  answers.  Tne  user  determines  me 
appropriate  input  and  tne  system  responds  witn  tne  answer  or 
anotner  menu.  Tnis  contributes  to  tne  ease  of  use  or  tne 
system  and  tne  untrained  user  can  become  proficient  in  a 
very  snort  time.  Tne  tecnnique  does  run  tne  risx  of  oeir.g 
too  slow  and  teiious  out  it  can  be  speeded  up  by  a  nign 
speed  terminal  and  fast  access  to  menus.  Figure  lil  is  an 
example  of  a  menu  from  tne  target  information  system. 
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Tne  Tanner  in  wnicn  tne  data  is  formatted  can  affect  tne 
efficiency  of  tne  operator  oy  influencing  bo  tr.  nis  speed  and 
nis  error  rate.  A  poorly  formatted  dialogue  car.  cause 
bewilderment,  anxiety  and  improper  input.  James  Martin  i  r. 
nis  boolc.  Design  of  ^an-Computer  Dialogue.  lists  twelve 
criteria  for  tne  design  of  menu  and  form  filling  screen 
formats.  These  criteria  were  used  in  tne  dcsigr.  and 
implementation  of  tne  target  information  system: 

1.  Display  a  small  amount  of  information  at  one  tire 

2.  Do  not  include  unwantea/unneeded  information 

3.  Have  one  idea  per  display 

4.  The  operator  response  Should  be  short 

5.  Tne  computer  should  always  respond  to  tne  operator 

5.  LTse  formats  designed  for  clarity 

7.  Strive  for  similarity  (position,  format,  terms) 

8.  Avoid  difficult  words  or  cnaracters 

9.  Provide  an  easy  means  for  correction 

13.  ^aie  instructions  to  tne  operator  stand  out 

11.  Clean  up  the  screen  wnen  possible 

12.  v’a.-ce  it  easy  for  tne  operator  to  asi  for  nelp 

S.  E.  Engle  and  E.  E.  Crania  i  r.  tneir  worst,  G  ui del 1  r.e  s 
for  Man/Display  Interface  ,  mention  many  i  if  f  e  re  r.  t  and  useful 
techniques  for  improving  tne  interactive  dialogue  and  the 
user  input.  Some  of  tne  more  important  points  used  m  tne 
design  of  the  target  information  system  are  paraphased  in 


tne  following  list  : 

Avcia  abbreoiations  ana  contractions 

Be  consistent  in  use  ana  meaning  of  tecr.nical  words 

Use  examples  to  supplement  Inst ructi or.s 

Be  consistent  in  presenting  iden ti ca i /s imilar  data 

Use  numbers  wnen  listing  selectable  items 

Place  most  probable  items  at  tna  top  of  tne  menu 

Standardize  screen  organization  and  ferret 

(Jive  user  directions  before  tne  list  of  ccoice? 

User  input  snould  be  iept  to  a  minimum 
Present  data  in  a  recognizable  order 
Avoid  verbosity  ana.  wordiness 

?.  ERROR  HANDLING 

Veil  designed  diagnostics  and  error  messages  can  gi: ids 
tne  user  to  enter  tne  correct  commands.  7nen  tne  system 
prompts  tne  user  tnat  an  error  nas  occurea,  it  snould  allow 
for  error  correction  immediately.  In  tne  menu  selection 
dialogues,  tne  range  of  options  is  predetermined  tv  tne 
system  and  only  a  valid  input  will  result  in  tne  appropriate 
closure.  Invalid  inputs  can  be  .easily  determined  and 
appropriate  guidance  provided  to  tne  user  in  tne  error 
message  to  obtain  tne  proper  input. 

form  filling  dialogue  can  cnecx  tne  field  len^tr.  and 
field  type  (for  example,  a  grid  location  would  consist  rf 
eignt  numbers  and  any  otner  input  would  be  invalid).  Error 


essages  must  indicate  tne  nature  of  tre  error  ana  new  tc 
ecover  frer  tne  error.  Vnen  appropriate,  tre  system  sreuii 
espond  witn  an  example  of  tne  proper  input.  Figure  22  below 
s  an  example  of  an  error  messaee  from  tr.e  target 
nformation  system: 


- ^ 

5NTSR  TARGET  NtJM£5R 

==>0036 

Tne  proper  format  for  a  target  number 
consists  of  2  letters  followed  by 
1  numbers,  for  example,  AA0057. 

Please  reenter  your  data. 


SNTSR  TARGET  NUMBER 


Figure  22.  Example  of  an  Error  vessaee. 

A  central  problem  in  nanaling  errors  is  in  providing  tne 
iser  witn  tne  rignt  Aind  of  information.  Even  experienced 
■sers  occassionally  require  assistance  in  some  portion  of 
be  system.  Accordinely,  a  user  nelp  function  nas  been 
.esi^ned  to  complement  tne  dialogue  and  provide  tne  user 
ritn  additional  detailed  but  concise  information  on  tre 
pproprlate  input.  In  some  cases,  tnis  function  is  built 
iebt  into  tre  ranee  of  options  of  tre  menu,  r.owever,  at  any 
ime  tne  user  can  receive  neip  or  more  information  by  simply 
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typing  a  "?  . 
sel f-explana tory , 
appropriate  and 
a r.i  error  ressases 


Wnen  toe  system  is 
it  is  designed  to  be 
neaniagf ui  instructions 


not  sux'f  icier,  ti, 
self-helping  w  it 
advisor/  7iessa<?e 


lie 
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71 1  APPLICATIONS  P.HCCrRAM  I  VPI}-MEPTATICN 

A.  STSTEy  IMPLEMENTATION 

.Eased  on  the  lesion  criteria  outlined  in  chapters  17.  7 
and  71,  tie  target  information  system  was  cooed,  compiled 
and  tested.  Each  module  was  coded  independently  of  me  ctner 
and  tested  in  its  own  environment .  Sirilarity  of  tie 
interface  was  Taintainel  between  each  module  and  was  the 
first  part  of  eacn  mcduie  coded.  After  tne  interface  «as  in 
place  and  wortcins?,  tne  module  was  filled  cut  to  perforr  tre 
system  functions.  After  eacn.  module  was  tested  and  debugged 
independently,  it  was  incorporated  into  the  sysla"’  where 
additional  testing  and  debugging  toox  place.  Tne  nett  module 
was  men  coded  after  tne  system  was  functioning  properly. 

Tne  Inter face  module  is  tne  main  system  program  and 
contains  tne  global  data  structures  am  tne  system.  pri-itive 
routines  sucn  as  clearing  tne  screen,  sKipping  lines,  ar.d 
printing  error  messages.  It  maices  tie  cdxis  to  tie  seg-^r.: 
procedures  from  a  master  menu.  Another  primary  function  cf 
this  module  is  to  ouiia  me  aairess  map  of  tne  records  at 
the  start  of  each  session  and  to  open  tne  system  data  files. 
This  module  compiled  to  SI  if  ^  bytes  cf  object  coca  «nicn  is 
four  '£  less  than  originally  expected. 

Tne  first  of  tne  segment  routines  is  tne  Inform  module. 
This  nodule  contains  system  operating  instructions. 
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doctrinal  explanation?  of  target  information  ter^s,  target 
analysis  guidelines,  security  requirements  am  examples  cf 
formats  used  in  tne  system.  It  is  basically  all  text  and 
serves  tc  inform  tne  user  of  tne  capabilities  of  tne  system. 
Tr.e  module  compiles  to  17,322  bytes  of  object  code. 

Tne  Initialize  module  is  designed  to  erase  tne  current 
data  files  and  completely  reinitialize  tne  system.  It 
performs  no  otner  function  for  tne  system.  It  builds  tne 
data  files  to  tne  required  size  and  fills  tn.e  file  * i t n 
empty  records.  It  compiles  to  2522  bytes  of  object  code. 

Tne  third  segment  procedure  is  tne  Target  module.  It 
contains  suD-modules  for  adding  a  target,  deleting  =  target, 
changing  current  tareet  information,  displaying  a  target  aid 
adding  a  BOA  to  tne  target  record,  yajor  difficulties  were 
encountered  in  loading  this  very  large  module  and  its 
involved  user  interface  into  main  memory  with  tne  operating 
system  cole  and  tne  system  Interface  module.  Initial 
compilation  of  tne  module  was  to  36,422  bytes.  Tne  main 
problem  was  tne  amount  of  text  tnat  the  user  interface  was 
consuming.  One  screen  frame  of  user  information  (advisories, 
explanations,  etc.;  usually  toon  1220  bytes  of  object  code. 
Tne  expense  of  so  mucn  text  m  tne  code  was  xuca  too  great 
for  tnis  module. 

Conseouently ,  a  decision  was  made  to  reduce  the  size  cf 
tne  module  by  putting  most  of  tne  text  in  separate  text 
files  on  tne  diskette  and  retrieving  these  fixes  from 
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secondary  storage  wner.  canea  5 v  me  program.  Tms  produced 
two  unpleasant  sid?  effects.  Pi rs  T ,  to?  interface  *  as  Slowed 
consiieraciy  since  it  now  too*  longer  to  place  a  user 
message  on  tne  screen  (aitneugn  tne  user  could  not  read  as 
fast  as  tne  output''  and  second,  tne  diskette  new  contained 
numerous  text  files  in  ad  line  r.  to  tne  cone  and  data  files 
snown  in  figure  7. 

Since  tne  Pascal  system  usea  four  ciocks  of  512  cytes 
earn  for  a  text  file  no  matter  now  small  tne  file  was,  tne 
54  text  files  toon  approximately  IliJ  £  oytes  of  secondary 
storage.  This  caused  tne  system  to  employ  tne  second  ALTOS 
distt  drive,  wnicn  nad  not  been  used  oreviousiv.  Tne 


resul tant 

reconf ieura  ticn 

Of 

tne 

secondary  storaec 

allocation 

is  snown  in 

figure 

23. 

Certain  menus  and 

recurring  messages  were  retained  in  me  target  module  to 
speed  tne  processing  and  decrease  user  wait  time. 

Tne  use  cf  tne  text  files  and  tne  reorganization  cf  tee 
2  DA.  routine  into  a  separate  segment  procedure  (caned  ty  tne 
Target  segment  procedure),  reduced  tne  module  to  I7. 220 
bytes  of  object  code  (19,320  cytes  wner.  me  LOA  procedure  is 
called).  Tnis  proved  a  satisfactory  solution  witnout  a 
significant  design  cnange.  Tne  direct  access  capability  of 
tne  Pascal  system  proved  cotn  accurate  and  fast  witr.  r,c 
apparent  wait  in  tne  process  time  between  a  request  for  a 
record  and  a  reply  to  tne  CRT. 
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Tne  last  module  implemented  was  tne  Query  module.  It 
emplovea  some  of  tne  menu  text  flies  used  by  tne  Target 
molule,  tnus  decreasing  its  node  size,  ar.l  proved  °asier  to 
implement  man  expected.  Welle  tne  query  selection  is 
limited  to  tne  loeical  "andING"  cf  elements  of  tr.e  donains 
of  tne  record,  tne  array  nrocessine  proved  to  ce  very  rapid 
and  well  witnin  tne  two  second  time  response  parameters. 
Loading  of  tne  data  case  query  file  was  stralgnt  forward  ar.d 
cnanges  in  tne  main  record,  performed  in  tne  target  module, 
were  being  correctly  reflected  in  tne  data  case  query  file. 
Wnile  initial  evaluation  of  tne  module  proved  satisfactory, 
it  is  felt  tnat  system  improvement  could  be  obtained  ty 
designing  an  interface  and  an  algoritnm  wnicn  allowed  betn 
logical  "ANTING”  and  "ORING”  of  attributes.  Tnis  segment 
procedure  compiles  to  bytes  of  object  code. 

Tne  final  sesment  procedure,  tne  Utility  module,  nas  net 
been  completely  implemented  due  to  programming  time 
constraints.  Eowever,  tne  complete  user  interface  is  in 
place  and  operational  and  gives  tne  user  tne  impression  tnat 
tr.e  system  is  operating.  Tne  erase  file  function  is 
operational  and  worses  effectively.  Tne  following  functions 
nave  not  been  implemented:  cnan^ine  tne  password  (requires 
design  of  tne  password  record  as  well  as  implementation), 
copying  tne  data  base  query  and  target  files  to  a  baexup 
diskette,  operations  on  tne  TAR3UL — displaying ,  renumbering , 
printlne  and  reinitiating  (tnis  also  requires  lesion  of  tne 
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T.ARBUI  record),  printing  target  cards  and  lists  ar.d  tne 
•'C'nputa  ti  on  and  display  ot  target  file  statistics.  Tne 
current  size  of  me  module  is  cvtes.  As  functions  are 
ailed  and  tr.e  size  increases,  rru.cn  of  tne  user  interface  can 
oe  transferee  to  text  files  to  tceep  tne  size  of  tne  module 
at  an  acceptable  level. 

Tne  entire  program  compiles  to  72  £  of  ocject  code,  56 
of  wnicn  is  contained  in  segment  procedures.  Toe  system 
source  code,  wnicn  is  contained  in  tne  Naval  Postgraduate 
Scnooi  tecnnical  report  entitled  A  Prototype  Program  for 
Target  Information  ( NPS52-£l-?£7)  .  is  over  52?*  lines  ion;-. 
Initial  testing  and  implementation  was  do^e  witr*  a  target 
list  size  of  lftf  targets  and  later  expanded  to  tr.e  required 
tZ'i)  target  maximum.  It  nas  been  debugged  for  execution  and 
tested  for  operational  accuracy.  .Ynile  initial  results  are 
very  satisfying  and  tne  system  proves  fast  ana  accurate, 
extensive  testing  to  include  field  testing  would  be  reuuirei 
before  tne  system  could  become  operational.  Additionally, 
tne  Utility  module  would  nave  to  oe  completed. 

Tnere  are  two  main  concerns  in  testing  tne  system. 
First,  trial  it  meets  tne  requirements  of  tne  target 
information  section  and  effectively  accomplisnes  its 
purpose. .. tne  automation  of  tne  target  information 
functions,  and  second,  tnat  tne  user  interface  is  as 
effective  as  it  proports  to  be.  Tnis  will  require  extensive 
testing  and  validation  as  well  as  operational  testing  and 


evaluation  in  appropriate  tactical  command  post  exercises 
voice  employ  tee  division  or  tee  VAB  fire  support 
coordination  center. 

3.  TECHNICAL  CONSIDERATIONS 

Tee  Pascal  program  listed  in  tee  tecnnical  report  is 
tra ns  porta  ole  to  oteer  UCSD  Pascal  systems  ard  wite 
modification  (random  access,  segment  procedures,  strings'  to 
any  Pascal  system.  Certain  aspects  of  tee  program  were 
implemented  to  conform  to  tne  Datamedia  Elite  25C0  viceo 
terminal.  Tels  terminal  nas  Si!  cnaracters  per  line  witn  24 
lines  of  display  witn  full  upper  and  lower  case  ASCII 
operating  at  a  data  rate  of  so 00  baud.  It  nas  a  ls52i) 
cnaracter  screen  capacity,  an  aipnanumeric  Keyboard  ar.d 
display  and  botn  synenronous  and  asynceronous  interface. 
Some  of  tne  special  cnaracters  used  in  tne  program  include: 


ASCII 

Decimal 

Function 

S3 

14 

DlinK  field  on 

CAN 

24 

Diinic  field  of 

BEL 

7 

bell/oeeper 

3S 

29 

roll  field  cr. 

US 

31 

clear  screen 

It  Is  recognized  teat  tne  design  and  implementation  is 
based  on  tne  ALTCS  ACS  3000-1  computer.  Advances  in 
microcomputer  tecnnolo?y  will  invariably  modify  tne 
environment  for  wnicn  tne  prototype  was  designed.  Tne 
addition  of  nard  disi  capabilities  to  microcomputer  systems 

1  IT 


? 


will  increase  tne  secondary  storage  space  us  well  as  tr.e 
processing  speed  now  avaiiaci0  w  i  t  r.  floppy  diskettes.  To*3 
current  system  can  certainly  function  effectively  in  sucn  a 
new  environment  but  tne  possibilities  cf  redesign  snouid  be 
considered,  if  tne  increase  in  efficiency  is  warranted  and 
tne  tine  span  between  a  new  implementation  and  tne 
introduction  of  '^IPASS  is  sufficiently  lor.*;. 

Since  tne  ’JCSD  Pascal  is  available  on  so  many  systems. 


wita  tne 

proper  setup  routines  tae 

system  i 

5  sufficiently 

portable 

provided  tae 

secondary 

s  t  orase 

capability  is 

available 

.  Tne  source 

code  is  c 

ompi ia  o is 

on  personal 

computers 

sucn  as  tne 

Apple  II  wren  tae  Pascal  system  card 

is  included  witn  a  5<s- 

K  memory 

altnougn 

tae  size  of 

secondary 

storage  (tne 

Apple  uses 

a  5  1/4  i 

non  mini-floppy 

dissette^ 

will  dictate  a 

realignment 

of  files 

and  a  f urtrer 

partitioning  of  system  software. 

C.  TACTICAL  CONSIDERATIONS 

Tnere  are  a  number  of  considerations  water,  involve  tne 
tactical  and  operational  aspects  of  target  information  wni-n 
bear  consideration  out  wnicn  are  beyond  tr.e  scope  of  iris 
tresis.  Tne  first  of  tnese  is  tne  survivability  cf  tne  ALTOS 
and  related  equipment  in  tne  field.  Special  nandiirm  ar.d 
care  is  required  of  eaca  item  as  well  as  tae  system  ar.i 
target  dlstettes.  Specific  instructions  for  tne  user  ir.  tne 
maintenance  and  aandllng  of  tae  system  must  be  determined 
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and  promulgated  to  tr.e  user.  Additionally,  ^Gwer 
requirements  and  tr.e  resultant  equipment  modifications  ->r 
adjustments  reeded  to  operate  in  a  field  environment  must  re 
considered . 

Tne  acquisition  and  use  of  tr.is  equipment  may  ce  cause 
to  examine  tn?  tames  of  organization  to  istsrs rn.e  tne 
proper  staffing  of  tne  target  information  section  since  a 
reduction  of  personnel  seers  rat.ner  3ssy  to  acr.i=ve . 
Additionally,  a  metnod  of  transferee  data  from  tr.e  Navy 
ASIS  computer  to  tne  system  microcomputer  sr.ouid  re 
investieated  and  addressed  since  transferee  tr.e  data 
electronically  between  tne  two  systems  is  preferable  to 
manually  transferee  tne  lata  into  tne  microcomputer  system. 
Concept  of  employment  of  tne  system  aboard  snip  (in  SACC  or 
in  landic?  force  spaces)  must  also  re  determined  and 
promulgated . 

Once  adopted  and  functional,  long  range  mans  must  be 
determined  for  a  transition  from  tne  system  to  we  VIFASS 
system.  These,  of  course,  are  locally  eenarated  reauirener.ts 
and  can  ce  addressed  in  tne  future.  It  is  anticipated  tne 
."ilFASS  will  require  extensive  operator  training  before  i: 
becomes  operational  wnereas  tne  microcomputer  prototype 
system  reouires  only  user  familiarization.  It  is  estimated 
tnat  tne  user  can  Deco, me  proficient  witn  tnis  system  a. ter  a 
one  hour  familiarization  period. 


Tne  rsaul renents  i or  maintaining  a  graphical  dispiay  cf 
cartels,  wniie  currently  soivacie  witn  computer  «rap me;, 
will  continue  to  ce  accomplished  by  the  use  of  ta-tical 
cattle  maps  covered  witn  acetate  overlays  wr.ere  tne 
situation  dictates.  Tais  system  maJces  no  attempt  tc  address 
tne  graphic  display  of  targets.  It  is  felt  teat  tne  display 
capabilities  cf  tne  MIFA.SS  system  will  adequately  satisfy 
tne  requirements  when  tne  system  is  introiU"ei  lute  tne 
fleet. 

D .  SYSTEM  REFINEMENTS 

¥nile  tne  system  meets  all  tne  requirements  identified 
for  tne  target  information  section,  tnere  are  a  number  of 
refinements  to  tne  program  vnicn  could  ce  inpi£",ertec  in  a 
later  version  of  tne  prototype  wmen  would  enhance  tne 
system  performance  and  provide  additional  capabilities  to 
tne  TIO.  Tnese  include  tne  following: 

1.  Expand! ne  tne  size  of  tne  target  file  teyond  tne 
current  2 Z iJ  target  maximum  if  tne  tactical  considerations 
of  future  battle  scenarios  dictate. 

d.  Logical  "ORING”  and  ” ANTING ”  of  record  attribute 
iocna ins  in  tne  tuery  module  to  provide  a  more  refined 
selectivity  of  tne  special  target  lists. 

3.  Inclusion  of  a  utility  routine  in  tne  query  module  tc 
print  tne  target  list  obtained  as  a  result  of  tne  query. 


4.  M  lew  tne  user  to  specify  altitude  ir.  feet,  ye  res  :  r 
re  ter  s  ani  nave  t.oe  sys  ter  convert  t  re  lata  to  re  te  rs  . 

5.  Find,  tre  number  and  designations  of  targets  witnr  a 
certain  radius  or  distance  of  anotner  target  (for  exams!’, 
a  class  F  target)  or  a  mown  grid  reference  point. 

5.  Provide  a  routine  for  seeping  tracK  of  tr.e  next 
available  target  number  from  tr.e  FFCC  oioc<  of  target 
nur be  rs . 

7.  Modification  of  tne  IJCSD  Pascal  operating  system 
command  prompt  to  allow  tr.e  user  only  one  choice  of 
option,  i.  e.,  to  run  tne  system  program  and  remove  tne 
filer  subroutine  from  nis  environment. 

8.  Plotting  of  artillery  firing  units  end  naval  gunfire 
support  stations  to  determine  automatically,  wnicb  targets 
are  witnin  tne  effective  range  of  specific  supporting 
arms. 

y .  P.  eduction  oi  -coding  cy  improved  algorithm  *  ar.d 
subroutines. 

liJ.  Provide  operator  training  ani  system  ma  ir.  tenence 
manuals  for  tne  system. 


71 1 1  COCCUS  IONS  AND  R£C  OMM  D  N  DAT  I  J.\  S 


A.  CONCLUSIONS 

Tnis  tnesis  nas  contended  tnat  tne  operation.!, 
e  r't'sc ti ver.es s  of  tne  fire  support  coordination  center  «cu:d 
ce  iTi pro men  cy  us  automation  of  tag  target  i  r.  f  o  T>‘'’  a  t  i  ^ r. 
function.  Funner ,  it  appears  tnat  tne  design  a"d 
implementation  of  a  suitacie  and  effective  system  is 
pcssiDle  now,  five  full  years  oefore  tne  introduction  of  tne 
yiFASS  computer  system  into  tne  Fleet  Marine  Forces. 

Tne  tnesis  nas  presented  one  sucn  design  using  a  c  =  ta 
oase  approac.n  on  a  typically  '•onfieured,  commercially 
avaiiacle  microcomputer  witn  a  user  interface  specifically 
designed  for  me  Marine  performing  tne  target  information 
functions  in  an  operational  environment.  An  evaluation  of 
tne  implemented  prototype  microcomputer  System  for  Target 
Information  (*ISTI)  nas  determined  tnat  tne  requirements  ar.u 
specifications  for  tne  system  as  described  in  cnapters  II 
and  III  nave  oeen  met  and  tnat  tne  program  operates 
effectively  and  efficiently. 

Tne  Dasic  soundness  of  tne  iesien  is  reflected  in  fctn 
tie  operational  effectiveness  of  tne  prototype  and  tne  lacX 
of  significant  cnanees  or  modiiicaticns  neeiel  to  meet  tne 
stated  system  requirements.  Tne  wording  prototype,  if 
employed  in  an  FSCC  in  its  present  state,  would  immediately 
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a 


increase  tr.e  operational  effectiveness  of  tne  target 
ir.for-’oticr.  section. 

aSCOMENEAIICMS 

Tne  design  ani  impiementa  tion  nas  ceen  snc*r.  to  oe  sound 
am,  based  on  tne  observed  effectiveness  of  tr.°  prototype 
program,  tne  following  recommendations  are  mace: 

i.  Tnat  tr.e  i*nplerr*»r.tat  ion  of  the  prototype  Microcomputer 
oyster  for  Target  Information  (MISTI)  oe  cor.tinv.ea  in 
accordance  * i t h  tne  design  criteria  outlined  rerein  and 
tne  system  refinenents  discussed  in  ccapter  VII. 
d.  Tnat  tne  resultant  system  be  tested  and  evaluated  at 
seiectea  Marine  Corps  commands  to  determine  its 
effectiveness  in  actual  tactical  operations. 

3.  Tnat  tne  Marine  Corps  adopt  tne  Microcomputer  System 
for  Target  Information  (MISTI)  cn  an  interim  basis  until 
tne  introduction  of  tne  WIFASS  system. 

4.  Tnat  appropriate  nardware  and  software  oe  provided  t: 
tr.e  tnree  Marine  Division  fire  support  coordination 
centers  in  order  to  employ  tnis  system. 

o.  That  the  Marine  Corps  Tactical  Software  Support 
Activity  (V,CTSSA)  evaluate  tne  Microcomputer  System  for 
Tareet  Information  (MISTI)  as  a  testbed  model  for  the 
software  interface  criteria  of  tne  targe t  information 


portion  of  the  MIFASS  system 


APPENDIX.  A 


DATA  I'ICTI 


Hecorls:  2 

Relationsnips:  l 

P. s r o r  1  s  Target 

?ri"a rv  ,<ey:  target  rur  b  =  r 

Secondary  iteys  :  rlassirication.  .ri 

location,  su poor  tin 
status 

Retrieval  teys :  target  number,  eri i 

Repeating  croups:  ETA  (DTD  surveili 

nc/type  rounds,  i 
ia^a^e  repcrt-i. 

Cardinality:  3  £2 
Deeres:  22 

Attritutss  ieagtn:  233  bytes  ir.  cas 

cc  bytes  for  ea 
3?i  by  tea  full  r 

Value  set  size:  15 1' 
lengtn:  fixed 

Record:  Tarest  Duery 

Primary  .tey:  target  r.uTter 

Secondary  cteys:  classification,  or : 

status,  type,  suppo 

Retrieval  *e,y:  target  nun cer 

Repeating  groups :  none 

Cardinality: 

:  3 


D<=>frree 


Attributes  ler.rtn:  43  eyre? 
Tame  sec  size:  152 
Lea?tn:  fixed 


Attribute  list:  Target  ^cor;  am  Target  Cuery  Recorc 

(Target  Cuery  Report  attributes  indicated  r.y 


A7TRI3CJTS 

r  ?C  rC  T 

ST 

^  n  v  r  « 

::vA  :m 

^Target  nun  car 

2  cnar,  4  in. t 

6 

cnar 

A  At  IT  1  -ZZ 

vGrid  location 

5  int 

c 

cnar 

r:i;r  ~r i  cai 

*A1 ti tuae 

a  i  n  t 

cnar 

?i < z-yyyy 

^Description 

42  cnar 

4 

o  cnar 

t  cnar 

s  triti 

Rena  rss 

42  cnar 

A 

cnar 

s  t  r  i  n  = 

^Classification 

l  cr.ar 

1 

cnar 

a  ^  r» 

At  ^  t  ~  » 

•Type 

4  cnar 

1 

cnar 

TAN  5,  VIS 

-i  »  y*  t  *  c* 

C  V  %  *  IN  ^ 

^Prio  ri ty 

3  cnar 

l 

cnar 

It  II»  lilt  17 

^Status 

2  cnar 

i 

cnar 

t  ?  "  X  7  U  I  \  - r  T 1 7  £ 

•Supporting  ir 
assigned 

4  cnar 

•* 

1 

cnar 

AIE,  ASTY.  u: 

n rn  tt  n  %  Am  v 

^  a.  r.  JV  «  •«  */«'i  — 

DTC  surveiii.  an~e 

o  int,  1  cnar 

7 

cnar 

ilitl  lA-.'f  1235^5 

firing  unit 

6  cnar 

« 

cnar 

string 

No. /type  rounds 

12  cnar 

12 

n  a  r 

s  t  r  i  r.  ? 

Damage  assessed 

11  cnar 

1 

cnar 

Damage  reported 

11  cnar 

+ 

X 

cnar 

Interdicted . 

neutralizes.,  Illuminates, 
damages,  destroyed, 
unknown,  unobserved. 
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APPENDIX  B  -  EXAMPLE  OF  SYSTEM  USER  INTERFACE 


This  appendix  illustrates  tne  menu  selection  format  of 
tne  user  interface  explained  in  detail  in  tne  preceeding 
chapters.  It  simulates  tne  user  operating  tne  query  module 
and  forming  a  list  of  targets  for  a  special  listing.  Tne 
fire  support  coordinator  nas  astted  tne  target  information 
officer  for  a  list  of  targets  which  are  to  be  considered  in 
tne  formulation  of  a  flat  suppression  fire  plan  prior  to  tne 
calling  of  close  air  support  aircraft  on  an  important 
landing  force  target. 

Essentially,  tne  list  must  include  all  targets  from  the 
following  categories: 

Type . SEAD  targets 

Classification. ..  .all  classes 

Priori  ty . I 

Status . active  targets 

Accuracy . all  categories 

Supporting  arm ... .artillery 

The  example  simulates  the  user  interface  of  actual 
system  operation  to  complete  tnis  query  as  specified  aoove. 
Each  page  represents  a  separate  frame  observed  by  tne  user 
on  tne  CRT  screen. 
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SPECIAL  TARGET  LISTINGS 

The  optio 

ns  are: 

1. 

Form  a  special  target  listing 

2. 

Continue  to  process 

3. 

Vrite  tne  special  list  to  tne  screen 

4. 

information  acout  tnis  procedure 

5. 

Return  to  previous  nenu 

PLEASE 

ENTER  OPTION  NUMBER 

Tne  user  enters  option  1 


i2e 


Categories  for  Special  Listing 


Tne  listing  can  contain  6  items  from  tne  below 


1.  Target  type 

2.  Classification 

3.  Supporting  arm  assigned 

4.  Priority 

5.  Accuracy 

6.  Status 

*  P.  Process  information 


Special  list  currently  contains  0  targets 
Please  start  a  new  listine. 


PLEASE  ENTER  OPTION  NUMBER 
==> 


User  enters  option  l  to  select  tne  tarset 


I2y 


menu 


type 


ENTER  TARGET  TIPS 
Tae  options  are: 

1 .  Tank 

2.  SEAD  tareet 

3.  Installation 

4.  Counter  Battery 

5.  Observation  Post 

6.  Terrain 

7.  Vesicles 

8.  Fortifications 

9.  Miscellaneous 

PLEASE  ENTER  OPTION  NUMBER 
==> 


User  enters 


a  2  for  tne  SEAD  targets 
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Categories  for  Special  listing 


Tne  listing  can  contain  b  items  from  tne  oeiow  menu: 

1.  Target  type  Already  Tairen 

2.  Classification 

3.  Supporting  arm  assigned 

4.  Priority 

5.  Accuracy 

6.  Status 

*  P.  Process  information 


Special 


list  currently  contains  42  targets. 


PLEASE  ENTER  OPTION  NUMBER 
==> 


User  enters  option  3  to  selec 


tne  supporting  arm 


L3; 


ENTER  SUPPORTING  ARM  ASSIGNED  TO  TARGET 


Tne  options  are: 

1.  ARTY 

2.  NGF 

3.  AIR 

4.  AIR,  ARTY 

5.  AiR,  NGF 

6.  ARTY,  NGF 

?.  AIR,  ARTY,  NGF 

8.  Otner 

9.  None 

PLEASE  ENTER  OPTION  NUMBER 
==> 


User  enters  option  1  to  select  artillery 


Categories  for  Special  Listing 


Tne  listing  can  contain  4  items  from  tne  beiov  menu: 

1.  Target  type  Already  Taien 

2.  Classification 

3.  Supporting  an  assigned  Already  TaKen 

4.  Priority 

5.  Accuracy 
S.  Status 

m  P.  Process  information 
Special  list  currently  contains  29  targets. 
PLEASE  ENTER  OPTION  NUMBER 


User  enters  option  4  to  select  tne  target  priority 


ENTER 

tarset  PRIORITY 

The  options  are: 

1 . 

I 

2. 

II 

3. 

III 

4. 

1/ 

PLEASE 

ENTER  OPTION  NUMBER 

User  selects  option  1  for  priority  I  targets 
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Categories  for  Special  Listing 


Tne  listing 

can  contain  3  items  from 

tne  oelow 

menu : 

1. 

Target  type 

A lready 

Tatcen 

o 

Classification 

3. 

Supporting  arm  assigned 

Already 

Tatcen 

4. 

Priority 

Already 

Tatcen 

5. 

Accuracy 

6. 

Status 

*  P. 

Process  information 

Special  list  currently  contains  16  targets. 

PLEASE  ENTER  OPTION  NUMBER 
==> 


User  enters  option  6  to  select 


tftp  target  status 
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ENTER  TARGET  STATUS  —ACTIVITY 


Tpe  options  are: 

1.  Active 

2.  Inactive 

PLEASE  ENTER  OPTION  NUMBER  AND  PRESS  RETURN 


User  seiects  option  l  for  active  targets 
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Categories  for  Special  Listlne 

1  The  listing 

can  contain  2  items  from 

the  below 

:nenu: 

1. 

Target  type 

Already 

Tairen 

2. 

Classification 

3. 

Supporting  arm  assiened 

Already 

TaKen 

4. 

Priority 

Already 

TaKen 

5. 

Accuracy 

6. 

Status 

Already 

TaKen 

*  P. 

Process  information 

Special 

list  currently  contains 

10  targets 

« 

PLEASE  ENTER  OPTION  NUMBER 

=  =  ^ 

User  nas  completed  the  query  and  now 
process  the  list  of  10  targets 


elects 


to 
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SPECIAL  TARGET  LISTINGS 

The  options  are: 

1. 

Form  a  special  tareet  listin* 

2. 

Continue  to  process 

3. 

Write  tne  special  list  to  tne  screen 

4. 

Information  atout  tnis  procedure 

5. 

Return  to  previous  menu 

PLEASE 

ENTER  OPTION  NUMBER 

! 

j 

L  33 


SPECIAL  TARGET  LISTINS 


Cateeories:  SEAD  ACTIVE  Prl  I  ARTY 


TGT  NO 

CL 

PR  I 

LOCATION 

AA0046* 

A 

I 

35647582 

AA0057* 

C 

I 

35452353 

AA0078 

A 

I 

35467787 

AA0156* 

A 

I 

35667746 

AA0122* 

D 

I 

35334563 

AA0144* 

B 

I 

35674664 

AA0167 

A 

I 

35455234 

NA0023* 

D 

I 

34556867 

AA018B* 

C 

I 

34567890 

AA0194* 

A 

I 

36087546 

alt 

SA 

DESCRIPTION 

100 

ARTY 

2  ZSU-23  PLT 

60 

ARTY 

SA-6  CLUSTER 

50 

ARTY 

12.5  AAA  SITE 

120 

ARTY 

S-60  PLT  IN  OPEN 

25 

ARTY 

SA-9  PLT  IN  TREES 

50 

ARTY 

14.5  AAA  SITE 

100 

ARTY 

ZU-23  AAA  CLUSTER 

20 

ARTY 

120  MM  AAA  CANNON 

150 

ARTY 

SA-8  IN  BUNKERS 

45 

ARTY 

S-60  AAA  CLUSTER 

NOTE:  *  indicates  tareet  list 


PLEASE  PRESS  RETURN  TO  CONTINUE 
==> 


The  user  presses  RETURN  to  continue 
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SPECIAL  TARGET  LISTINGS 


The  options  are: 

1.  Form  a  special  tareet  listing 

2.  Continue  to  process 

3.  Write  tae  special  list  to  tae  screen 

4.  Information  about  this  procedure 

5.  Return  to  previous  menu 

PLEASE  ENTER  OPTION  NUMBER 
==> 


Tne  user  begins  a  new  query  or  returns  to  tne  main  menu 
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